Rendering location specific virtual content in any location

ABSTRACT

Augmented reality systems and methods for creating, saving and rendering designs comprising multiple items of virtual content in a three-dimensional (3D) environment of a user. The designs may be saved as a scene, which is built by a user from pre-built sub-components, built components, and/or previously saved scenes. Location information, expressed as a saved scene anchor and position relative to the saved scene anchor for each item of virtual content, may also be saved. Upon opening the scene, the saved scene anchor node may be correlated to a location within the mixed reality environment of the user for whom the scene is opened. The virtual items of the scene may be positioned with the same relationship to that location as they have to the saved scene anchor node. That location may be selected automatically and/or by user input.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/593,227, filed on Oct. 4, 2019, entitled “RENDERING LOCATION SPECIFICVIRTUAL CONTENT IN ANY LOCATION,” which claims the benefit under 35U.S.C. § 119(e) of U.S. Provisional Patent Application Ser. No.62/742,061, filed on Oct. 5, 2018, entitled “RENDERING LOCATION SPECIFICVIRTUAL CONTENT IN ANY LOCATION.” The contents of these applications areincorporated herein by reference in their entirety.

FIELD

The present disclosure relates to virtual reality and augmented realityimaging and visualization systems and more particularly to automaticallyrepositioning a virtual object in a three-dimensional (3D) space.

BACKGROUND

Modern computing and display technologies have facilitated thedevelopment of systems for so called “virtual reality”, “augmentedreality”, or “mixed reality” experiences, wherein digitally reproducedimages or portions thereof are presented to a user in a manner whereinthey seem to be, or may be perceived as, real. A virtual reality, or“VR”, scenario typically involves presentation of digital or virtualimage information without transparency to other actual real-world visualinput; an augmented reality, or “AR”, scenario typically involvespresentation of digital or virtual image information as an augmentationto visualization of the actual world around the user; a mixed reality,or “MR”, related to merging real and virtual worlds to produce newenvironments where physical and virtual objects co-exist and interact inreal time. As it turns out, the human visual perception system is verycomplex, and producing a VR, AR, or MR technology that facilitates acomfortable, natural-feeling, rich presentation of virtual imageelements amongst other virtual or real-world imagery elements ischallenging. Systems and methods disclosed herein address variouschallenges related to VR, AR and MR technology.

SUMMARY

Various embodiments of an augmented reality system for rendering virtualcontent in any location are described.

Details of one or more implementations of the subject matter describedin this specification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages will becomeapparent from the description, the drawings, and the claims. Neitherthis summary nor the following detailed description purports to defineor limit the scope of the inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an illustration of a mixed reality scenario with certainvirtual reality objects, and certain physical objects viewed by aperson.

FIG. 2 schematically illustrates an example of a wearable system.

FIG. 3 schematically illustrates aspects of an approach for simulatingthree-dimensional imagery using multiple depth planes.

FIG. 4 schematically illustrates an example of a waveguide stack foroutputting image information to a user.

FIG. 5 shows example exit beams that may be outputted by a waveguide.

FIG. 6 is a schematic diagram showing an optical system including awaveguide apparatus, an optical coupler subsystem to optically couplelight to or from the waveguide apparatus, and a control subsystem, usedin the generation of a multi-focal volumetric display, image, or lightfield.

FIG. 7 is a block diagram of an example of a wearable system.

FIG. 8 is a process flow diagram of an example of a method of renderingvirtual content in relation to recognized objects.

FIG. 9 is a block diagram of another example of a wearable system.

FIG. 10 is a process flow diagram of an example of a method fordetermining user input to a wearable system.

FIG. 11 is a process flow diagram of an example of a method forinteracting with a virtual user interface.

FIG. 12 illustrates an example process 1200 of a user interaction usingthe system and methods described herein.

FIG. 13A illustrates an example process 1300 a for saving a scene usingthe system and methods described herein.

FIG. 13B illustrates an example process 1300 b for rendering a framedscene using the system and methods described herein.

FIG. 14 illustrates an example process 1400 for loading a scene usingthe system and methods described herein.

FIG. 15 illustrates an example process 1500 for loading a scene usingthe system and methods described herein.

FIG. 16 illustrates an example process 1600 for loading a scene usingthe system and methods described herein.

FIG. 17 illustrates a simplified flowchart illustrating a method forcreating a 3D mesh of a scene using multiple frames of captured depthmaps.

FIG. 18 is a sketch of an exemplary user interface presenting to a userof an augmented reality system a menu of pre-built virtual objects forincorporation into a scene.

FIG. 19 is a sketch of an exemplary user interface presenting to a userof an augmented reality system an icon for selecting a virtual cameraand a menu of saved scenes available to be opened in the user'senvironment.

FIG. 20 is a sketch of a portion of the exemplary user interface of FIG.19 illustrating the user moving a selected saved scene icon from themenu.

FIG. 21A is a sketch of a portion of an exemplary user environment of anaugmented reality system in which a user is providing input to move avisual anchor node that has associated with it saved scene objects shownin a preview mode;

FIG. 21B is a sketch of the portion of an exemplary user environment ofFIG. 21A in which the user is providing input to select a LOAD icon, toindicate loading of a saved scene;

FIG. 21C is a sketch of the portion of an exemplary user environment ofFIG. 21B, after the user selected the LOAD icon, and the saved sceneobjects, associated with the visual anchor node the user is providinginput to select a LOAD icon, to indicate full instantiation of savedscene objects in a location indicated by the specified position of thevisual anchor node.

Throughout the drawings, reference numbers may be re-used to indicatecorrespondence between referenced elements. The drawings are provided toillustrate example embodiments described herein and are not intended tolimit the scope of the disclosure.

DETAILED DESCRIPTION

Overview

In an AR/MR environment, a user may want to create, build, and/or designnew virtual objects. A user may be an engineer who needs to create aprototype for a work project, or the user may be a teenager in highschool who enjoys building and creating for fun, such as a person mightbuild with physical elements in complex LEGO® kits and puzzles. In somesituations, the user may need to build virtual objects with complexstructures that may take a while to build, over the course of severaldays, months, or even years, for example. In some embodiments, thevirtual objects with complex structures may comprise repeatingcomponents arranged or used in different ways. As a result, there aresituations in which a user may wish to build components, sometimes frompre-built sub-components, and save one or more of the built componentsas separate saved scenes, and then build various designs utilizing theone or more previously saved scenes.

For example, the user may wish to create a landscape design utilizingthe AR/MR wearable device. The wearable device may have an applicationdownloaded that stores or can access pre-built sub-components, such asvarious types of trees (e.g. pine tree, oak tree), flowers (e.g.gladiolas, sunflowers, etc.), and various other plants (e.g. bushes,vines, etc.). The landscape designer may realize through experience thatcertain plants go well together. The landscape designer may utilize theapplication on the AR/MR wearable device to create built componentscomprising these known preferred combinations of plants. As one example,a built component may comprise raspberry plants, tulip plants, andclover, for example, or any other suitable companion plant arrangement.After saving one or more scenes comprising one or more pre-fabricatedsub-components combined to form one or more built components, thelandscape designer may then wish to create a full landscape design forhis/her home. The landscape design may comprise one or more saved scenesand/or one or more built components, and/or one or more pre-builtsub-components. The landscape design may be designed more quickly andeasily by utilizing saved scenes, than if the landscape designer hadstarted with only pre-built sub-components.

Saved scenes may also allow for more flexible design options. Forexample, some applications may only enable the user to choose frompre-built sub-components which may be more or less complex than thedesigner needs. The ability to save built components may enable theoriginal downloaded application to be smaller in size than anapplication that does not enable saving built components because fewerpre-built sub-components may be required.

In some embodiments, the application may enable the user to create adesign in one location and then re-open the saved design at the exactsame location at a later time. In some embodiments, the application mayenable the user to create a design in one location and then re-open thesaved design at any other location in the real world. For example, thismay enable the user to create a design in his/her office and thenre-open the design for presentation during a meeting in a meeting room.

However, some applications may only enable re-opening a saved design ata specific location in the real world, which may be a problem for theuser who may create a design in the user's office but needs to share thedesign in a meeting room. In systems that only enable re-opening a saveddesign at a specific location, if the real world location is no longeravailable (e.g. the user's office building burns down), the saved designis no longer accessible because it depends on that particular location(for example it may comprise objects digitally anchored or placedrelative to real world objects that do not exist at the second locationor have differing characteristics). Additionally, systems that onlyenable the user to re-open a saved design once per session or once perroom, for example, may not meet the user's need. For example, a user maywish to present the user's design during a meeting from severalperspectives simultaneously, and thus may wish to load multiple copiesof the saved design into the meeting room.

The systems and methods of the present application solve these problems.Such a system, for example, may enable a user to specify virtual contentbased on what the user perceives in an augmented reality environment.The system may then save a digital representation of that virtualcontent as a scene. At a later time, a user may instruct the same, orpossibly a different, augmented reality system to open the saved scene.That augmented reality system may, as part of opening the saved scene,incorporate virtual content of the saved scene into a mixed realityenvironment for the user of the augmented reality system such that theuser for whom the scene is opened may then perceive the virtual content.

A scene, in some embodiments, may be assembled from multiple builtcomponents, which may be built by specifying combinations of pre-builtsubcomponents. The built components may be of any complexity, and mayeven be, for example, scenes that were previously saved. Further, thebuilt components need not be assembled from pre-built subcomponents.Components also may be built using tools supplied by the augmentedreality system. As one example, the system may process data about aphysical object collected with sensors of the augmented reality systemto form a digital representation of that physical object. This digitalrepresentation may be used to render a representation of the physicalobject, thus serving as a virtual object. Further, it is not arequirement that the scene to be saved have multiple built components oreven multiple pre-built sub-components. The scene may have a singlecomponent. Thus, it should be understood that description of saving oropening a scene refers to manipulation of virtual content of any levelof complexity and from any source.

A saved scene may comprise at least one saved scene anchor node (e.g. aparent node in a hierarchical data structure that may represent thesaved scene at a coordinate system in space) for the saved scene.Virtual content of the scene may have an established spatialrelationship with respect to the saved scene anchor node such that, oncethe location of the saved scene anchor node is established in anenvironment of a user of an augmented reality system, the locationwithin that environment of the virtual content of the scene can bedetermined by the system. Using this location information, the systemmay render the virtual content of the scene to that user. The locationof the virtual content of the saved scene within the environment of auser of an augmented reality system may be determined, for example, byuser input positioning a visual anchor node, representing a locationwithin the environment of the user. A user may manipulate the locationof the visual anchor node through a virtual user interface of theaugmented reality system. The virtual content of the saved scene may berendered with the saved scene anchor node aligned with the visual anchornode.

In some scenarios, the saved scene anchor node may correspond to a fixedlocation in the physical world, and the saved scene may be re-openedwith the virtual content of the scene having the same position relativeto that location that it had upon saving of the scene. In that case auser may experience the scene if that fixed location in the physicalworld is within the user's environment when the scene is opened. In sucha scenario, the saved scene anchor node may comprise a persistentcoordinate frame (PCF), which may be a point with a coordinate framethat is derived from objects that exist in the real world that do notchange, much, at all, or infrequently, over time. This locationassociated with the saved scene anchor node may be represented by asaved PCF. The saved PCF may be utilized to re-open the saved scene suchthat the saved scene is rendered at the exact same location in spacewhere the saved scene was rendered when it was saved.

Alternatively, the location in the physical world at which an augmentedreality system may render content of a saved scene to a user may not befixed. The location may be dependent on user input or on the user'ssurroundings when the scene is opened. For example, if the user needs toopen the saved scene at a different location, the user is able to do soby utilizing an adjustable visual anchor node or nodes as appropriate.

Alternatively or additionally, the system may conditionally position thevirtual content of the saved scene in a fixed location, if the savedscene is re-opened for a user while that fixed location is within theirenvironment or within their field of view. If not, the system mayprovide a user interface through which the user may provide inputindicating the location in which the virtual content of the saved sceneis to be located. The system may accomplish this by identifying the PCFclosest to the user (current PCF). If the current PCF matches the savedPCF, the system may re-open the saved scene with the virtual content ofthe saved scene at the exact same location as when the saved scene wassaved by placing the virtual objects of the saved scene at a fixedspatial configuration relative to the PCF. If the current PCF does notmatch the saved PCF, the system may preview place the saved scene at adefault location or at a location chosen by the user. Based on thepreview placement, the user or system may move the entire saved scene toa desired location, and tell the system to instantiate the scene. Insome embodiments, the saved scene may be rendered at the defaultlocation in a preview format, lacking some details or functions of thesaved scene. Instantiating a scene may comprise rendering the full savedscene to the user including all visual, physics, and other saved scenedata.

One skilled in the art may approach the problem of saving scenes bycreating a process for saving built sub-components and a separateprocess for saving scenes. Exemplary systems as described in the presentapplication may merge the two processes and provide a single userinteraction. This has a computer operational benefit. For example,writing and managing a single process instead of two processes mayimprove reliability. Additionally, the processor may be able to operatefaster because the processor only needs to access one program instead ofaccessing and switching between two or more processes. Additionally,there may be a usability benefit to the user in that the user only needsto learn one interaction instead of two or more.

If the user wishes to view several virtual objects in one room withoutsaving the scene, for example 20 different virtual objects in the user'soffice, the system would need to track the 20 different object locationsrelative to the real world. One benefit of the systems and methods ofthe present application, is that all 20 virtual objects may be savedinto a single scene, where only a single saved scene anchor node (e.g.PCF) would need to be tracked (20 objects would be placed relative tothe PCF, not relative to the world, which may require less compute).This may have the computer operational benefit of less computation,which may lead to less battery use or less heat generated duringprocessing, and/or may enable the application to run on a smallerprocessor.

The systems and methods disclosed may enable a simple, easy, unifieduser experience for saving and/or re-opening a scene within anapplication by creating a single user interaction in each of multipledifferent situations. Re-opening a scene may comprise loading and/orinstantiating a scene. Three examples of situations in which a user mayre-open a scene with the same interaction are: In Situation 1, the usermay wish to re-open a saved scene to appear in the exact same locationand environment in which the scene was saved (e.g. the saved PCF matchesthe current PCF). In Situation 2, the user may wish to re-open a savedscene to appear in the exact same location in which the scene was saved,but with the environment different (e.g. saved PCF matches the currentPCF, but the digital mesh describing the physical environment haschanged). For example, the user may save and re-open a saved scene inthe user's office at work, but the user may have added an extra table tothe office. In Situation 3, the user may wish to re-open a saved sceneto appear at a different location comprising a different environmentthan the scene was saved (e.g. saved PCF does not match current PCF,saved world mesh does not match current world mesh).

Regardless of the situation, the user may interact with the systemthrough the same user interface, with controls that are available ineach of multiple situations. The user interface may be, for example, agraphical user interface in which controls are associated with iconsvisible to the user and the user activates a control by taking an actionthat indicates selection of an icon. In order to save a scene, forexample, the user may select a camera icon (1900, FIG. 19 ), frame thescene, and then capture the image.

Regardless of the situation, in order to load a scene, the user may, forexample, select a saved scene icon, such as icon 1910 (FIG. 19 ). Theuser may pull the saved scene icon out of a user menu (which may createa preview of the saved scene), an example of which is illustrated inFIGS. 19 and 20 . The user may then release the saved scene icon (whichmay place a visual anchor node relative to the saved scene objects). Theuser may optionally move the visual anchor node in order to move thesaved scene relative to the real world, and then instantiate the scene(which may send full saved scene data into the render pipeline).

One skilled in the art may approach the three situations as threedifferent problems and would create three separate solutions (e.g.programs) and user interactions to address those problems. The systemsand methods of the present application solve these three problems with asingle program. This has a computer operational benefit. For example,writing and managing a single process instead of two processes improvesreliability. Additionally, the processor is able to operate fasterbecause the processor only needs to access one program instead ofswitching between multiple processes. An additional computer operationalbenefit is provided because the system only needs to track a singlepoint in the real world (e.g. the anchor node).

Examples of 3D Display of a Wearable System

A wearable system (also referred to herein as an augmented reality (AR)system) can be configured to present 2D or 3D virtual images to a user.The images may be still images, frames of a video, or a video, incombination or the like. The wearable system can include a wearabledevice that can present a VR, AR, or MR environment, alone or incombination, for user interaction. The wearable device can be ahead-mounted device (HMD) which is used interchangeably as an AR device(ARD). Further, for the purpose of the present disclosure, the term “AR”is used interchangeably with the term “MR”.

FIG. 1 depicts an illustration of a mixed reality scenario, as viewed bya person using an MR system, with certain virtual reality objects andcertain physical objects. FIG. 1 , depicts an MR scene 100 in which auser of an MR technology sees a real-world, park-like setting 110featuring people, trees, buildings in the background, and a concreteplatform 120. In addition to these items, the user of the MR technologyalso perceives that he “sees” a robot statue 130 standing upon thereal-world platform 120, and a cartoon-like avatar character 140 flyingby which seems to be a personification of a bumble bee, even thoughthese elements do not exist in the real world.

In order for the 3D display to produce a true sensation of depth, andmore specifically, a simulated sensation of surface depth, it may bedesirable for each point in the display's visual field to generate anaccommodative response corresponding to its virtual depth. If theaccommodative response to a display point does not correspond to thevirtual depth of that point, as determined by the binocular depth cuesof convergence and stereopsis, the human eye may experience anaccommodation conflict, resulting in unstable imaging, harmful eyestrain, headaches, and, in the absence of accommodation information,almost a complete lack of surface depth.

VR, AR, and MR experiences can be provided by display systems havingdisplays in which images corresponding to a plurality of depth planesare provided to a viewer. The images may be different for each depthplane (e.g., provide slightly different presentations of a scene orobject) and may be separately focused by the viewer's eyes, therebyhelping to provide the user with depth cues based on the accommodationof the eye required to bring into focus different image features for thescene located on different depth plane or based on observing differentimage features on different depth planes being out of focus. Asdiscussed elsewhere herein, such depth cues provide credible perceptionsof depth.

FIG. 2 illustrates an example of wearable system 200. The wearablesystem 200 includes a display 220, and various mechanical and electronicmodules and systems to support the functioning of display 220. Thedisplay 220 may be coupled to a frame 230, which is wearable by a user,wearer, or viewer 210. The display 220 can be positioned in front of theeyes of the user 210. The display 220 can present AR/VR/MR content to auser. The display 220 can comprise a head mounted display that is wornon the head of the user. In some embodiments, a speaker 240 is coupledto the frame 230 and positioned adjacent the ear canal of the user (insome embodiments, another speaker, not shown, is positioned adjacent theother ear canal of the user to provide for stereo/shapeable soundcontrol). The display 220 can include an audio sensor (e.g., amicrophone) for detecting an audio stream from the environment on whichto perform voice recognition.

The wearable system 200 can include an outward-facing imaging system 464(shown in FIG. 4 ) which observes the world in the environment aroundthe user. The wearable system 200 can also include an inward-facingimaging system 462 (shown in FIG. 4 ) which can track the eye movementsof the user. The inward-facing imaging system may track either one eye'smovements or both eyes' movements. The inward-facing imaging system 462may be attached to the frame 230 and may be in electrical communicationwith the processing modules 260 or 270, which may process imageinformation acquired by the inward-facing imaging system to determine,e.g., the pupil diameters or orientations of the eyes, eye movements oreye pose of the user 210.

As an example, the wearable system 200 can use the outward-facingimaging system 464 or the inward-facing imaging system 462 to acquireimages that reveal a pose of the user. The images may be still images,frames of a video, or a video, or any combination of such sources ofinformation or other like sources of information.

The display 220 can be operatively coupled 250, such as by a wired leador wireless connectivity, to a local data processing module 260 whichmay be mounted in a variety of configurations, such as fixedly attachedto the frame 230, fixedly attached to a helmet or hat worn by the user,embedded in headphones, or otherwise removably attached to the user 210(e.g., in a backpack-style configuration, in a belt-coupling styleconfiguration).

The local processing and data module 260 may comprise a hardwareprocessor, as well as digital memory, such as non-volatile memory (e.g.,flash memory), both of which may be utilized to assist in theprocessing, caching, and storage of data. The data may include data a)captured from sensors (which may be, e.g., operatively coupled to theframe 230 or otherwise attached to the user 210), such as image capturedevices (e.g., cameras in the inward-facing imaging system or theoutward-facing imaging system), audio sensors (e.g., microphones),inertial measurement units (IMUs), accelerometers, compasses, globalpositioning system (GPS) units, radio devices, or gyroscopes; or b)acquired or processed using remote processing module 270 or remote datarepository 280, possibly for passage to the display 220 after suchprocessing or retrieval. The local processing and data module 260 may beoperatively coupled by communication links 262 or 264, such as via wiredor wireless communication links, to the remote processing module 270 orremote data repository 280 such that these remote modules are availableas resources to the local processing and data module 260. In addition,remote processing module 280 and remote data repository 280 may beoperatively coupled to each other.

In some embodiments, the remote processing module 270 may comprise oneor more processors configured to analyze and process data or imageinformation. In some embodiments, the remote data repository 280 maycomprise a digital data storage facility, which may be available throughthe internet or other networking configuration in a “cloud” resourceconfiguration. In some embodiments, all data is stored and allcomputations are performed in the local processing and data module,allowing fully autonomous use from a remote module.

The human visual system is complicated and providing a realisticperception of depth is challenging. Without being limited by anyparticular theory, it is believed that viewers of an object may perceivethe object as being three-dimensional due to a combination of vergenceand accommodation. Vergence movements (i.e., rolling movements of thepupils toward or away from each other to converge the lines of sight ofthe eyes to fixate upon an object) of the two eyes relative to eachother are closely associated with focusing (or “accommodation”) of thelenses of the eyes. Under normal conditions, changing the focus of thelenses of the eyes, or accommodating the eyes, to change focus from oneobject to another object at a different distance will automaticallycause a matching change in vergence to the same distance, under arelationship known as the “accommodation-vergence reflex.” Likewise, achange in vergence will trigger a matching change in accommodation,under normal conditions. Display systems that provide a better matchbetween accommodation and vergence may form more realistic andcomfortable simulations of three-dimensional imagery.

FIG. 3 illustrates aspects of an approach for simulating athree-dimensional imagery using multiple depth planes. With reference toFIG. 3 , objects at various distances from eyes 302 and 304 on thez-axis are accommodated by the eyes 302 and 304 so that those objectsare in focus. The eyes 302 and 304 assume particular accommodated statesto bring into focus objects at different distances along the z-axis.Consequently, a particular accommodated state may be said to beassociated with a particular one of depth planes 306, which has anassociated focal distance, such that objects or parts of objects in aparticular depth plane are in focus when the eye is in the accommodatedstate for that depth plane. In some embodiments, three-dimensionalimagery may be simulated by providing different presentations of animage for each of the eyes 302 and 304, and also by providing differentpresentations of the image corresponding to each of the depth planes.While shown as being separate for clarity of illustration, it will beappreciated that the fields of view of the eyes 302 and 304 may overlap,for example, as distance along the z-axis increases. In addition, whileshown as flat for the ease of illustration, it will be appreciated thatthe contours of a depth plane may be curved in physical space, such thatall features in a depth plane are in focus with the eye in a particularaccommodated state. Without being limited by theory, it is believed thatthe human eye typically can interpret a finite number of depth planes toprovide depth perception. Consequently, a highly believable simulationof perceived depth may be achieved by providing, to the eye, differentpresentations of an image corresponding to each of these limited numberof depth planes.

Waveguide Stack Assembly

FIG. 4 illustrates an example of a waveguide stack for outputting imageinformation to a user. A wearable system 400 includes a stack ofwaveguides, or stacked waveguide assembly 480 that may be utilized toprovide three-dimensional perception to the eye/brain using a pluralityof waveguides 432 b, 434 b, 436 b, 438 b, 4400 b. In some embodiments,the wearable system 400 may correspond to wearable system 200 of FIG. 2, with FIG. 4 schematically showing some parts of that wearable system200 in greater detail. For example, in some embodiments, the waveguideassembly 480 may be integrated into the display 220 of FIG. 2 .

With continued reference to FIG. 4 , the waveguide assembly 480 may alsoinclude a plurality of features 458, 456, 454, 452 between thewaveguides. In some embodiments, the features 458, 456, 454, 452 may belenses. In other embodiments, the features 458, 456, 454, 452 may not belenses. Rather, they may simply be spacers (e.g., cladding layers orstructures for forming air gaps).

The waveguides 432 b, 434 b, 436 b, 438 b, 440 b or the plurality oflenses 458, 456, 454, 452 may be configured to send image information tothe eye with various levels of wavefront curvature or light raydivergence. Each waveguide level may be associated with a particulardepth plane and may be configured to output image informationcorresponding to that depth plane. Image injection devices 420, 422,424, 426, 428 may be utilized to inject image information into thewaveguides 440 b, 438 b, 436 b, 434 b, 432 b, each of which may beconfigured to distribute incoming light across each respectivewaveguide, for output toward the eye 410. Light exits an output surfaceof the image injection devices 420, 422, 424, 426, 428 and is injectedinto a corresponding input edge of the waveguides 440 b, 438 b, 436 b,434 b, 432 b. In some embodiments, a single beam of light (e.g., acollimated beam) may be injected into each waveguide to output an entirefield of cloned collimated beams that are directed toward the eye 410 atparticular angles (and amounts of divergence) corresponding to the depthplane associated with a particular waveguide.

In some embodiments, the image injection devices 420, 422, 424, 426, 428are discrete displays that each produce image information for injectioninto a corresponding waveguide 440 b, 438 b, 436 b, 434 b, 432 b,respectively. In some other embodiments, the image injection devices420, 422, 424, 426, 428 are the output ends of a single multiplexeddisplay which may, e.g., pipe image information via one or more opticalconduits (such as fiber optic cables) to each of the image injectiondevices 420, 422, 424, 426, 428.

A controller 460 controls the operation of the stacked waveguideassembly 480 and the image injection devices 420, 422, 424, 426, 428.The controller 460 includes programming (e.g., instructions in anon-transitory computer-readable medium) that regulates the timing andprovision of image information to the waveguides 440 b, 438 b, 436 b,434 b, 432 b. In some embodiments, the controller 460 may be a singleintegral device, or a distributed system connected by wired or wirelesscommunication channels. The controller 460 may be part of the processingmodules 260 or 270 (illustrated in FIG. 2 ) in some embodiments.

The waveguides 440 b, 438 b, 436 b, 434 b, 432 b may be configured topropagate light within each respective waveguide by total internalreflection (TIR). The waveguides 440 b, 438 b, 436 b, 434 b, 432 b mayeach be planar or have another shape (e.g., curved), with major top andbottom surfaces and edges extending between those major top and bottomsurfaces. In the illustrated configuration, the waveguides 440 b, 438 b,436 b, 434 b, 432 b may each include light extracting optical elements440 a, 438 a, 436 a, 434 a, 432 a that are configured to extract lightout of a waveguide by redirecting the light, propagating within eachrespective waveguide, out of the waveguide to output image informationto the eye 410. Extracted light may also be referred to as outcoupledlight, and light extracting optical elements may also be referred to asoutcoupling optical elements. An extracted beam of light is outputted bythe waveguide at locations at which the light propagating in thewaveguide strikes a light redirecting element. The light extractingoptical elements (440 a, 438 a, 436 a, 434 a, 432 a) may, for example,be reflective or diffractive optical features. While illustrateddisposed at the bottom major surfaces of the waveguides 440 b, 438 b,436 b, 434 b, 432 b for ease of description and drawing clarity, in someembodiments, the light extracting optical elements 440 a, 438 a, 436 a,434 a, 432 a may be disposed at the top or bottom major surfaces, or maybe disposed directly in the volume of the waveguides 440 b, 438 b, 436b, 434 b, 432 b. In some embodiments, the light extracting opticalelements 440 a, 438 a, 436 a, 434 a, 432 a may be formed in a layer ofmaterial that is attached to a transparent substrate to form thewaveguides 440 b, 438 b, 436 b, 434 b, 432 b. In some other embodiments,the waveguides 440 b, 438 b, 436 b, 434 b, 432 b may be a monolithicpiece of material and the light extracting optical elements 440 a, 438a, 436 a, 434 a, 432 a may be formed on a surface or in the interior ofthat piece of material.

With continued reference to FIG. 4 , as discussed herein, each waveguide440 b, 438 b, 436 b, 434 b, 432 b is configured to output light to forman image corresponding to a particular depth plane. For example, thewaveguide 432 b nearest the eye may be configured to deliver collimatedlight, as injected into such waveguide 432 b, to the eye 410. Thecollimated light may be representative of the optical infinity focalplane. The next waveguide up 434 b may be configured to send outcollimated light which passes through the first lens 452 (e.g., anegative lens) before it can reach the eye 410. First lens 452 may beconfigured to create a slight convex wavefront curvature so that theeye/brain interprets light coming from that next waveguide up 434 b ascoming from a first focal plane closer inward toward the eye 410 fromoptical infinity. Similarly, the third up waveguide 436 b passes itsoutput light through both the first lens 452 and second lens 454 beforereaching the eye 410. The combined optical power of the first and secondlenses 452 and 454 may be configured to create another incrementalamount of wavefront curvature so that the eye/brain interprets lightcoming from the third waveguide 436 b as coming from a second focalplane that is even closer inward toward the person from optical infinitythan was light from the next waveguide up 434 b.

The other waveguide layers (e.g., waveguides 438 b, 440 b) and lenses(e.g., lenses 456, 458) are similarly configured, with the highestwaveguide 440 b in the stack sending its output through all of thelenses between it and the eye for an aggregate focal powerrepresentative of the closest focal plane to the person. To compensatefor the stack of lenses 458, 456, 454, 452 when viewing/interpretinglight coming from the world 470 on the other side of the stackedwaveguide assembly 480, a compensating lens layer 430 may be disposed atthe top of the stack to compensate for the aggregate power of the lensstack 458, 456, 454, 452 below. Such a configuration provides as manyperceived focal planes as there are available waveguide/lens pairings.Both the light extracting optical elements of the waveguides and thefocusing aspects of the lenses may be static (e.g., not dynamic orelectro-active). In some alternative embodiments, either or both may bedynamic using electro-active features.

With continued reference to FIG. 4 , the light extracting opticalelements 440 a, 438 a, 436 a, 434 a, 432 a may be configured to bothredirect light out of their respective waveguides and to output thislight with the appropriate amount of divergence or collimation for aparticular depth plane associated with the waveguide. As a result,waveguides having different associated depth planes may have differentconfigurations of light extracting optical elements, which output lightwith a different amount of divergence depending on the associated depthplane. In some embodiments, as discussed herein, the light extractingoptical elements 440 a, 438 a, 436 a, 434 a, 432 a may be volumetric orsurface features, which may be configured to output light at specificangles. For example, the light extracting optical elements 440 a, 438 a,436 a, 434 a, 432 a may be volume holograms, surface holograms, and/ordiffraction gratings. Light extracting optical elements, such asdiffraction gratings, are described in U.S. Patent Publication No.2015/0178939, published Jun. 25, 2015, which is incorporated byreference herein in its entirety.

In some embodiments, the light extracting optical elements 440 a, 438 a,436 a, 434 a, 432 a are diffractive features that form a diffractionpattern, or “diffractive optical element” (also referred to herein as a“DOE”). Preferably, the DOE has a relatively low diffraction efficiencyso that only a portion of the light of the beam is deflected away towardthe eye 410 with each intersection of the DOE, while the rest continuesto move through a waveguide via total internal reflection. The lightcarrying the image information can thus be divided into a number ofrelated exit beams that exit the waveguide at a multiplicity oflocations and the result is a fairly uniform pattern of exit emissiontoward the eye 304 for this particular collimated beam bouncing aroundwithin a waveguide.

In some embodiments, one or more DOEs may be switchable between “on”state in which they actively diffract, and “off” state in which they donot significantly diffract. For instance, a switchable DOE may comprisea layer of polymer dispersed liquid crystal, in which microdropletscomprise a diffraction pattern in a host medium, and the refractiveindex of the microdroplets can be switched to substantially match therefractive index of the host material (in which case the pattern doesnot appreciably diffract incident light) or the microdroplet can beswitched to an index that does not match that of the host medium (inwhich case the pattern actively diffracts incident light).

In some embodiments, the number and distribution of depth planes ordepth of field may be varied dynamically based on the pupil sizes ororientations of the eyes of the viewer. Depth of field may changeinversely with a viewer's pupil size. As a result, as the sizes of thepupils of the viewer's eyes decrease, the depth of field increases suchthat one plane that is not discernible because the location of thatplane is beyond the depth of focus of the eye may become discernible andappear more in focus with reduction of pupil size and commensurate withthe increase in depth of field. Likewise, the number of spaced apartdepth planes used to present different images to the viewer may bedecreased with the decreased pupil size. For example, a viewer may notbe able to clearly perceive the details of both a first depth plane anda second depth plane at one pupil size without adjusting theaccommodation of the eye away from one depth plane and to the otherdepth plane. These two depth planes may, however, be sufficiently infocus at the same time to the user at another pupil size withoutchanging accommodation.

In some embodiments, the display system may vary the number ofwaveguides receiving image information based upon determinations ofpupil size or orientation, or upon receiving electrical signalsindicative of particular pupil size or orientation. For example, if theuser's eyes are unable to distinguish between two depth planesassociated with two waveguides, then the controller 460 (which may be anembodiment of the local processing and data module 260) can beconfigured or programmed to cease providing image information to one ofthese waveguides. Advantageously, this may reduce the processing burdenon the system, thereby increasing the responsiveness of the system. Inembodiments in which the DOEs for a waveguide are switchable between theon and off states, the DOEs may be switched to the off state when thewaveguide does receive image information.

In some embodiments, it may be desirable to have an exit beam meet thecondition of having a diameter that is less than the diameter of the eyeof a viewer. However, meeting this condition may be challenging in viewof the variability in size of the viewer's pupils. In some embodiments,this condition is met over a wide range of pupil sizes by varying thesize of the exit beam in response to determinations of the size of theviewer's pupil. For example, as the pupil size decreases, the size ofthe exit beam may also decrease. In some embodiments, the exit beam sizemay be varied using a variable aperture.

The wearable system 400 can include an outward-facing imaging system 464(e.g., a digital camera) that images a portion of the world 470. Thisportion of the world 470 may be referred to as the field of view (FOV)of a world camera and the imaging system 464 is sometimes referred to asan FOV camera. The entire region available for viewing or imaging by aviewer may be referred to as the field of regard (FOR). The FOR mayinclude 4π steradians of solid angle surrounding the wearable system 400because the wearer can move his body, head, or eyes to perceivesubstantially any direction in space. In other contexts, the wearer'smovements may be more constricted, and accordingly the wearer's FOR maysubtend a smaller solid angle. Images obtained from the outward-facingimaging system 464 can be used to track gestures made by the user (e.g.,hand or finger gestures), detect objects in the world 470 in front ofthe user, and so forth.

The wearable system 400 can also include an inward-facing imaging system466 (e.g., a digital camera), which observes the movements of the user,such as the eye movements and the facial movements. The inward-facingimaging system 466 may be used to capture images of the eye 410 todetermine the size and/or orientation of the pupil of the eye 304. Theinward-facing imaging system 466 can be used to obtain images for use indetermining the direction the user is looking (e.g., eye pose) or forbiometric identification of the user (e.g., via iris identification). Insome embodiments, at least one camera may be utilized for each eye, toseparately determine the pupil size or eye pose of each eyeindependently, thereby allowing the presentation of image information toeach eye to be dynamically tailored to that eye. In some otherembodiments, the pupil diameter or orientation of only a single eye 410(e.g., using only a single camera per pair of eyes) is determined andassumed to be similar for both eyes of the user. The images obtained bythe inward-facing imaging system 466 may be analyzed to determine theuser's eye pose or mood, which can be used by the wearable system 400 todecide which audio or visual content should be presented to the user.The wearable system 400 may also determine head pose (e.g., headposition or head orientation) using sensors such as IMUs,accelerometers, gyroscopes, etc.

The wearable system 400 can include a user input device 466 by which theuser can input commands to the controller 460 to interact with thewearable system 400. For example, the user input device 466 can includea trackpad, a touchscreen, a joystick, a multiple degree-of-freedom(DOF) controller, a capacitive sensing device, a game controller, akeyboard, a mouse, a directional pad (D-pad), a wand, a haptic device, atotem, a component that senses movements of the user recognized by thesystem as inputs (e.g. a virtual user input device), and so forth. Amulti-DOF controller can sense user input in some or all possibletranslations (e.g., left/right, forward/backward, or up/down) orrotations (e.g., yaw, pitch, or roll) of the controller. A multi-DOFcontroller which supports the translation movements may be referred toas a 3DOF while a multi-DOF controller which supports the translationsand rotations may be referred to as 6DOF. In some cases, the user mayuse a finger (e.g., a thumb) to press or swipe on a touch-sensitiveinput device to provide input to the wearable system 400 (e.g., toprovide user input to a user interface provided by the wearable system400). The user input device 466 may be held by the user's hand duringthe use of the wearable system 400. The user input device 466 can be inwired or wireless communication with the wearable system 400.

FIG. 5 shows an example of exit beams outputted by a waveguide. Onewaveguide is illustrated, but it will be appreciated that otherwaveguides in the waveguide assembly 480 may function similarly, wherethe waveguide assembly 480 includes multiple waveguides. Light 520 isinjected into the waveguide 432 b at the input edge 432 c of thewaveguide 432 b and propagates within the waveguide 432 b by TIR. Atpoints where the light 520 impinges on the DOE 432 a, a portion of thelight exits the waveguide as exit beams 510. The exit beams 510 areillustrated as substantially parallel but they may also be redirected topropagate to the eye 410 at an angle (e.g., forming divergent exitbeams), depending on the depth plane associated with the waveguide 432b. It will be appreciated that substantially parallel exit beams may beindicative of a waveguide with light extracting optical elements thatoutcouple light to form images that appear to be set on a depth plane ata large distance (e.g., optical infinity) from the eye 410. Otherwaveguides or other sets of light extracting optical elements may outputan exit beam pattern that is more divergent, which would require the eye410 to accommodate to a closer distance to bring it into focus on theretina and would be interpreted by the brain as light from a distancecloser to the eye 410 than optical infinity.

FIG. 6 is a schematic diagram showing an optical system including awaveguide apparatus, an optical coupler subsystem to optically couplelight to or from the waveguide apparatus, and a control subsystem, usedin the generation of a multi-focal volumetric display, image, or lightfield. The optical system can include a waveguide apparatus, an opticalcoupler subsystem to optically couple light to or from the waveguideapparatus, and a control subsystem. The optical system can be used togenerate a multi-focal volumetric, image, or light field. The opticalsystem can include one or more primary planar waveguides 632 a (only oneis shown in FIG. 6 ) and one or more DOEs 632 b associated with each ofat least some of the primary waveguides 632 a. The planar waveguides 632b can be similar to the waveguides 432 b, 434 b, 436 b, 438 b, 440 bdiscussed with reference to FIG. 4 . The optical system may employ adistribution waveguide apparatus to relay light along a first axis(vertical or Y-axis in view of FIG. 6 ), and expand the light'seffective exit pupil along the first axis (e.g., Y-axis). Thedistribution waveguide apparatus may, for example, include adistribution planar waveguide 622 b and at least one DOE 622 a(illustrated by double dash-dot line) associated with the distributionplanar waveguide 622 b. The distribution planar waveguide 622 b may besimilar or identical in at least some respects to the primary planarwaveguide 632 b, having a different orientation therefrom. Likewise, atleast one DOE 622 a may be similar to or identical in at least somerespects to the DOE 632 a. For example, the distribution planarwaveguide 622 b or DOE 622 a may be comprised of the same materials asthe primary planar waveguide 632 b or DOE 632 a, respectively.Embodiments of the optical display system 600 shown in FIG. 6 can beintegrated into the wearable system 200 shown in FIG. 2 .

The relayed and exit-pupil expanded light may be optically coupled fromthe distribution waveguide apparatus into the one or more primary planarwaveguides 632 b. The primary planar waveguide 632 b can relay lightalong a second axis, preferably orthogonal to first axis (e.g.,horizontal or X-axis in view of FIG. 6 ). Notably, the second axis canbe a non-orthogonal axis to the first axis. The primary planar waveguide632 b expands the light's effective exit pupil along that second axis(e.g., X-axis). For example, the distribution planar waveguide 622 b canrelay and expand light along the vertical or Y-axis, and pass that lightto the primary planar waveguide 632 b which can relay and expand lightalong the horizontal or X-axis.

The optical system may include one or more sources of colored light(e.g., red, green, and blue laser light) 610 which may be opticallycoupled into a proximal end of a single mode optical fiber 640. A distalend of the optical fiber 640 may be threaded or received through ahollow tube 642 of piezoelectric material. The distal end protrudes fromthe tube 642 as fixed-free flexible cantilever 644. The piezoelectrictube 642 can be associated with four quadrant electrodes (notillustrated). The electrodes may, for example, be plated on the outside,outer surface or outer periphery or diameter of the tube 642. A coreelectrode (not illustrated) may also be located in a core, center, innerperiphery or inner diameter of the tube 642.

Drive electronics 650, for example electrically coupled via wires 660,drive opposing pairs of electrodes to bend the piezoelectric tube 642 intwo axes independently. The protruding distal tip of the optical fiber644 has mechanical modes of resonance. The frequencies of resonance candepend upon a diameter, length, and material properties of the opticalfiber 644. By vibrating the piezoelectric tube 642 near a first mode ofmechanical resonance of the fiber cantilever 644, the fiber cantilever644 can be caused to vibrate, and can sweep through large deflections.

By stimulating resonant vibration in two axes, the tip of the fibercantilever 644 is scanned biaxially in an area filling two-dimensional(2D) scan. By modulating an intensity of light source(s) 610 insynchrony with the scan of the fiber cantilever 644, light emerging fromthe fiber cantilever 644 can form an image. Descriptions of such a setup are provided in U.S. Patent Publication No. 2014/0003762, which isincorporated by reference herein in its entirety.

A component of an optical coupler subsystem can collimate the lightemerging from the scanning fiber cantilever 644. The collimated lightcan be reflected by mirrored surface 648 into the narrow distributionplanar waveguide 622 b which contains the at least one diffractiveoptical element (DOE) 622 a. The collimated light can propagatevertically (relative to the view of FIG. 6 ) along the distributionplanar waveguide 622 b by TIR, and in doing so repeatedly intersectswith the DOE 622 a. The DOE 622 a preferably has a low diffractionefficiency. This can cause a fraction (e.g., 10%) of the light to bediffracted toward an edge of the larger primary planar waveguide 632 bat each point of intersection with the DOE 622 a, and a fraction of thelight to continue on its original trajectory down the length of thedistribution planar waveguide 622 b via TIR.

At each point of intersection with the DOE 622 a, additional light canbe diffracted toward the entrance of the primary waveguide 632 b. Bydividing the incoming light into multiple outcoupled sets, the exitpupil of the light can be expanded vertically by the DOE 622 a in thedistribution planar waveguide 622 b. This vertically expanded lightcoupled out of distribution planar waveguide 622 b can enter the edge ofthe primary planar waveguide 632 b.

Light entering primary waveguide 632 b can propagate horizontally(relative to the view of FIG. 6 ) along the primary waveguide 632 b viaTIR. As the light intersects with DOE 632 a at multiple points as itpropagates horizontally along at least a portion of the length of theprimary waveguide 632 b via TIR. The DOE 632 a may advantageously bedesigned or configured during operation to have a phase profile that isa summation of a linear diffraction pattern and a radially symmetricdiffractive pattern, to produce both deflection and focusing of thelight. The DOE 632 a may advantageously have a low diffractionefficiency (e.g., 10%), so that only a portion of the light of the beamis deflected toward the eye of the view with each intersection of theDOE 632 a while the rest of the light continues to propagate through theprimary waveguide 632 b via TIR.

At each point of intersection between the propagating light and the DOE632 a, a fraction of the light is diffracted toward the adjacent face ofthe primary waveguide 632 b allowing the light to escape the TIR, andemerge from the face of the primary waveguide 632 b. In someembodiments, the radially symmetric diffraction pattern of the DOE 632 aadditionally imparts a focus level to the diffracted light, both shapingthe light wavefront (e.g., imparting a curvature) of the individual beamas well as steering the beam at an angle that matches the designed focuslevel.

Accordingly, these different pathways can cause the light to be coupledout of the primary planar waveguide 632 b by a multiplicity of DOEs 632a at different angles, focus levels, or yielding different fill patternsat the exit pupil. Different fill patterns at the exit pupil can bebeneficially used to create a light field display with multiple depthplanes. Each layer in the waveguide assembly or a set of layers (e.g., 3layers) in the stack may be employed to generate a respective color(e.g., red, blue, green). Thus, for example, a first set of threeadjacent layers may be employed to respectively produce red, blue andgreen light at a first focal depth. A second set of three adjacentlayers may be employed to respectively produce red, blue and green lightat a second focal depth. Multiple sets may be employed to generate afull 3D or 4D color image light field with various focal depths.

Other Components of the Wearable System

In many implementations, the wearable system may include othercomponents in addition or in alternative to the components of thewearable system described above. The wearable system may, for example,include one or more haptic devices or components. The haptic devices orcomponents may be operable to provide a tactile sensation to a user. Forexample, the haptic devices or components may provide a tactilesensation of pressure or texture when touching virtual content (e.g.,virtual objects, virtual tools, other virtual constructs). The tactilesensation may replicate a feel of a physical object which a virtualobject represents, or may replicate a feel of an imagined object orcharacter (e.g., a dragon) which the virtual content represents. In someimplementations, haptic devices or components may be worn by the user(e.g., a user wearable glove). In some implementations, haptic devicesor components may be held by the user.

The wearable system may, for example, include one or more physicalobjects which are manipulable by the user to allow input or interactionwith the wearable system. These physical objects may be referred toherein as totems. Some totems may take the form of inanimate objects,such as for example, a piece of metal or plastic, a wall, a surface oftable. In certain implementations, the totems may not actually have anyphysical input structures (e.g., keys, triggers, joystick, trackball,rocker switch). Instead, the totem may simply provide a physicalsurface, and the wearable system may render a user interface so as toappear to a user to be on one or more surfaces of the totem. Forexample, the wearable system may render an image of a computer keyboardand trackpad to appear to reside on one or more surfaces of a totem. Forexample, the wearable system may render a virtual computer keyboard andvirtual trackpad to appear on a surface of a thin rectangular plate ofaluminum which serves as a totem. The rectangular plate does not itselfhave any physical keys or trackpad or sensors. However, the wearablesystem may detect user manipulation or interaction or touches with therectangular plate as selections or inputs made via the virtual keyboardor virtual trackpad. The user input device 466 (shown in FIG. 4 ) may bean embodiment of a totem, which may include a trackpad, a touchpad, atrigger, a joystick, a trackball, a rocker or virtual switch, a mouse, akeyboard, a multi-degree-of-freedom controller, or another physicalinput device. A user may use the totem, alone or in combination withposes, to interact with the wearable system or other users.

Examples of haptic devices and totems usable with the wearable devices,HMD, and display systems of the present disclosure are described in U.S.Patent Publication No. 2015/0016777, which is incorporated by referenceherein in its entirety.

Example Wearable Systems, Environments, and Interfaces

A wearable system may employ various mapping related techniques in orderto achieve high depth of field in the rendered light fields. In mappingout the virtual world, it is advantageous to know all the features andpoints in the real world to accurately portray virtual objects inrelation to the real world. To this end, FOV images captured from usersof the wearable system can be added to a world model by including newpictures that convey information about various points and features ofthe real world. For example, the wearable system can collect a set ofmap points (such as 2D points or 3D points) and find new map points torender a more accurate version of the world model. The world model of afirst user can be communicated (e.g., over a network such as a cloudnetwork) to a second user so that the second user can experience theworld surrounding the first user.

FIG. 7 is a block diagram of an example of an MR system 700 operable toprocess data related to an MR environment, such as a room. The MR system700 may be configured to receive input (e.g., visual input 702 from theuser's wearable system, stationary input 704 such as room cameras,sensory input 706 from various sensors, gestures, totems, eye tracking,user input from the user input device 466 etc.) from one or more userwearable systems (e.g., wearable system 200 or display system 220) orstationary room systems (e.g., room cameras, etc.). The wearable systemscan use various sensors (e.g., accelerometers, gyroscopes, temperaturesensors, movement sensors, depth sensors, GPS sensors, inward-facingimaging system, outward-facing imaging system, etc.) to determine thelocation and various other attributes of the environment of the user.This information may further be supplemented with information fromstationary cameras in the room that may provide images or various cuesfrom a different point of view. The image data acquired by the cameras(such as the room cameras and/or the cameras of the outward-facingimaging system) may be reduced to a set of mapping points.

One or more object recognizers 708 can crawl through the received data(e.g., the collection of points) and recognize or map points, tagimages, attach semantic information to objects with the help of a mapdatabase 710. The map database 710 may comprise various points collectedover time and their corresponding objects. The various devices and themap database can be connected to each other through a network (e.g.,LAN, WAN, etc.) to access the cloud.

Based on this information and collection of points in the map database,the object recognizers 708 a . . . 708 n (of which only objectrecognizers 708 a and 708 n are shown for simplicity) may recognizeobjects in an environment. For example, the object recognizers canrecognize faces, persons, windows, walls, user input devices,televisions, documents (e.g., travel tickets, driver's license, passportas described in the security examples herein), other objects in theuser's environment, etc. One or more object recognizers may bespecialized for objects with certain characteristics. For example, theobject recognizer 708 a may be used to recognizer faces, while anotherobject recognizer may be used recognize documents.

The object recognitions may be performed using a variety of computervision techniques. For example, the wearable system can analyze theimages acquired by the outward-facing imaging system 464 (shown in FIG.4 ) to perform scene reconstruction, event detection, video tracking,object recognition (e.g., persons or documents), object pose estimation,facial recognition (e.g., from a person in the environment or an imageon a document), learning, indexing, motion estimation, or image analysis(e.g., identifying indicia within documents such as photos, signatures,identification information, travel information, etc.), and so forth. Oneor more computer vision algorithms may be used to perform these tasks.Non-limiting examples of computer vision algorithms include:Scale-invariant feature transform (SIFT), speeded up robust features(SURF), oriented FAST and rotated BRIEF (ORB), binary robust invariantscalable keypoints (BRISK), fast retina keypoint (FREAK), Viola-Jonesalgorithm, Eigenfaces approach, Lucas-Kanade algorithm, Horn-Schunkalgorithm, Mean-shift algorithm, visual simultaneous location andmapping (vSLAM) techniques, a sequential Bayesian estimator (e.g.,Kalman filter, extended Kalman filter, etc.), bundle adjustment,Adaptive thresholding (and other thresholding techniques), IterativeClosest Point (ICP), Semi Global Matching (SGM), Semi Global BlockMatching (SGBM), Feature Point Histograms, various machine learningalgorithms (such as e.g., support vector machine, k-nearest neighborsalgorithm, Naive Bayes, neural network (including convolutional or deepneural networks), or other supervised/unsupervised models, etc.), and soforth.

The object recognitions can additionally or alternatively be performedby a variety of machine learning algorithms. Once trained, the machinelearning algorithm can be stored by the HMD. Some examples of machinelearning algorithms can include supervised or non-supervised machinelearning algorithms, including regression algorithms (such as, forexample, Ordinary Least Squares Regression), instance-based algorithms(such as, for example, Learning Vector Quantization), decision treealgorithms (such as, for example, classification and regression trees),Bayesian algorithms (such as, for example, Naive Bayes), clusteringalgorithms (such as, for example, k-means clustering), association rulelearning algorithms (such as, for example, a-priori algorithms),artificial neural network algorithms (such as, for example, Perceptron),deep learning algorithms (such as, for example, Deep Boltzmann Machine,or deep neural network), dimensionality reduction algorithms (such as,for example, Principal Component Analysis), ensemble algorithms (suchas, for example, Stacked Generalization), and/or other machine learningalgorithms. In some embodiments, individual models can be customized forindividual data sets. For example, the wearable device can generate orstore a base model. The base model may be used as a starting point togenerate additional models specific to a data type (e.g., a particularuser in a telepresence session), a data set (e.g., a set of additionalimages obtained of the user in the telepresence session), conditionalsituations, or other variations. In some embodiments, the wearable HMDcan be configured to utilize a plurality of techniques to generatemodels for analysis of the aggregated data. Other techniques may includeusing pre-defined thresholds or data values.

Based on this information and collection of points in the map database,the object recognizers 708 a to 708 n may recognize objects andsupplement objects with semantic information to give life to theobjects. For example, if the object recognizer recognizes a set ofpoints to be a door, the system may attach some semantic information(e.g., the door has a hinge and has a 90 degree movement about thehinge). If the object recognizer recognizes a set of points to be amirror, the system may attach semantic information that the mirror has areflective surface that can reflect images of objects in the room. Thesemantic information can include affordances of the objects as describedherein. For example, the semantic information may include a normal ofthe object. The system can assign a vector whose direction indicates thenormal of the object. Over time the map database grows as the system(which may reside locally or may be accessible through a wirelessnetwork) accumulates more data from the world. Once the objects arerecognized, the information may be transmitted to one or more wearablesystems. For example, the MR system 700 may include information about ascene happening in California. The information about the scene may betransmitted to one or more users in New York. Based on data receivedfrom an FOV camera and other inputs, the object recognizers and othersoftware components can map the points collected from the variousimages, recognize objects etc., such that the scene may be accurately“passed over” to a second user, who may be in a different part of theworld. The environment 700 may also use a topological map forlocalization purposes.

FIG. 8 is a process flow diagram of an example of a method 800 ofrendering virtual content in relation to recognized objects. The method800 describes how a virtual scene may be presented to a user of thewearable system. The user may be geographically remote from the scene.For example, the user may be in New York, but may want to view a scenethat is presently going on in California, or may want to go on a walkwith a friend who resides in California.

At block 810, the wearable system may receive input from the user andother users regarding the environment of the user. This may be achievedthrough various input devices, and knowledge already possessed in themap database. The user's FOV camera, sensors, GPS, eye tracking, etc.,convey information to the system at block 810. The system may determinesparse points based on this information at block 820. The sparse pointsmay be used in determining pose data (e.g., head pose, eye pose, bodypose, or hand gestures) that can be used in displaying and understandingthe orientation and position of various objects in the user'ssurroundings. The object recognizers 708 a-708 n may crawl through thesecollected points and recognize one or more objects using a map databaseat block 830. This information may then be conveyed to the user'sindividual wearable system at block 840, and the desired virtual scenemay be accordingly displayed to the user at block 850. For example, thedesired virtual scene (e.g., user in CA) may be displayed at theappropriate orientation, position, etc., in relation to the variousobjects and other surroundings of the user in New York.

FIG. 9 is a block diagram of another example of a wearable system. Inthis example, the wearable system 900 comprises a map, which may includemap data for the world. The map may partly reside locally on thewearable system, and may partly reside at networked storage locationsaccessible by wired or wireless network (e.g., in a cloud system). Apose process 910 may be executed on the wearable computing architecture(e.g., processing module 260 or controller 460) and utilize data fromthe map to determine position and orientation of the wearable computinghardware or user. Pose data may be computed from data collected on thefly as the user is experiencing the system and operating in the world.The data may comprise images, data from sensors (such as inertialmeasurement units, which generally comprise accelerometer and gyroscopecomponents) and surface information pertinent to objects in the real orvirtual environment.

A sparse point representation may be the output of a simultaneouslocalization and mapping (e.g., SLAM or vSLAM, referring to aconfiguration wherein the input is images/visual only) process. Thesystem can be configured to not only find out where in the world thevarious components are, but what the world is made of. Pose may be abuilding block that achieves many goals, including populating the mapand using the data from the map.

In one embodiment, a sparse point position may not be completelyadequate on its own, and further information may be needed to produce amultifocal AR, VR, or MR experience. Dense representations, generallyreferring to depth map information, may be utilized to fill this gap atleast in part. Such information may be computed from a process referredto as Stereo 940, wherein depth information is determined using atechnique such as triangulation or time-of-flight sensing. Imageinformation and active patterns (such as infrared patterns created usingactive projectors) may serve as input to the Stereo process 940. Asignificant amount of depth map information may be fused together, andsome of this may be summarized with a surface representation. Forexample, mathematically definable surfaces may be efficient (e.g.,relative to a large point cloud) and digestible inputs to otherprocessing devices like game engines. Thus, the output of the stereoprocess (e.g., a depth map) 940 may be combined in the fusion process930. Pose 950 may be an input to this fusion process 930 as well, andthe output of fusion 930 becomes an input to populating the map process920. Sub-surfaces may connect with each other, such as in topographicalmapping, to form larger surfaces, and the map becomes a large hybrid ofpoints and surfaces.

To resolve various aspects in a mixed reality process 960, variousinputs may be utilized. For example, in the embodiment depicted in FIG.9 , Game parameters may be inputs to determine that the user of thesystem is playing a monster battling game with one or more monsters atvarious locations, monsters dying or running away under variousconditions (such as if the user shoots the monster), walls or otherobjects at various locations, and the like. The world map may includeinformation regarding where such objects are relative to each other, tobe another valuable input to mixed reality. Pose relative to the worldbecomes an input as well and plays a key role to almost any interactivesystem.

Controls or inputs from the user are another input to the wearablesystem 900. As described herein, user inputs can include visual input,gestures, totems, audio input, sensory input, etc. In order to movearound or play a game, for example, the user may need to instruct thewearable system 900 regarding what he or she wants to do. Beyond justmoving oneself in space, there are various forms of user controls thatmay be utilized. In one embodiment, a totem (e.g. a user input device),or an object such as a toy gun may be held by the user and tracked bythe system. The system preferably will be configured to know that theuser is holding the item and understand what kind of interaction theuser is having with the item (e.g., if the totem or object is a gun, thesystem may be configured to understand location and orientation, as wellas whether the user is clicking a trigger or other sensed button orelement which may be equipped with a sensor, such as an IMU, which mayassist in determining what is going on, even when such activity is notwithin the field of view of any of the cameras.)

Hand gesture tracking or recognition may also provide input information.The wearable system 900 may be configured to track and interpret handgestures for button presses, for gesturing left or right, stop, grab,hold, etc. For example, in one configuration, the user may want to flipthrough emails or a calendar in a non-gaming environment, or do a “fistbump” with another person or player. The wearable system 900 may beconfigured to leverage a minimum amount of hand gesture, which may ormay not be dynamic. For example, the gestures may be simple staticgestures like open hand for stop, thumbs up for ok, thumbs down for notok; or a hand flip right, or left, or up/down for directional commands.

Eye tracking is another input (e.g., tracking where the user is lookingto control the display technology to render at a specific depth orrange). In one embodiment, vergence of the eyes may be determined usingtriangulation, and then using a vergence/accommodation model developedfor that particular person, accommodation may be determined. Eyetracking can be performed by the eye camera(s) to determine eye gaze(e.g., direction or orientation of one or both eyes). Other techniquescan be used for eye tracking such as, e.g., measurement of electricalpotentials by electrodes placed near the eye(s) (e.g.,electrooculography).

Voice recognition can be another input, which can be used alone or incombination with other inputs (e.g., totem tracking, eye tracking,gesture tracking, etc.). The system 900 can include an audio sensor(e.g., a microphone) that receives an audio stream from the environment.The received audio stream can be processed (e.g., by processing modules260, 270 or central server 1650) to recognize a user's voice (from othervoices or background audio), to extract commands, parameters, etc. fromthe audio stream. For example, the system 900 may identify from an audiostream that the phrase “show me your identification” was said, identifythat this phrase was said by the wearer of the system 900 (e.g., asecurity inspector rather than another person in the inspector'senvironment), and extract from the phrase and the context of thesituation (e.g., a security checkpoint) that there is an executablecommand to be performed (e.g., computer vision analysis of something inthe wearer's FOV) and an object for which the command is to be performedon (“your identification”). The system 900 can incorporate speakerrecognition technology to determine who is speaking (e.g., whether thespeech is from the wearer of the ARD or another person or voice (e.g., arecorded voice transmitted by a loudspeaker in the environment)) as wellas speech recognition technology to determine what is being said. Voicerecognition techniques can include frequency estimation, hidden Markovmodels, Gaussian mixture models, pattern matching algorithms, neuralnetworks, matrix representation, Vector Quantization, speakerdiarisation, decision trees, and dynamic time warping (DTW) technique.Voice recognition techniques can also include anti-speaker techniques,such as cohort models, and world models. Spectral features may be usedin representing speaker characteristics

With regard to the camera systems, the example wearable system 900 shownin FIG. 9 can include three pairs of cameras: a relative wide FOV orpassive SLAM pair of cameras arranged to the sides of the user's face, adifferent pair of cameras oriented in front of the user to handle thestereo imaging process 940 and also to capture hand gestures andtotem/object tracking in front of the user's face. The FOV cameras andthe pair of cameras for the stereo process 940 may be a part of theoutward-facing imaging system 464 (shown in FIG. 4 ). The wearablesystem 900 can include eye tracking cameras (which may be a part of aninward-facing imaging system 462 shown in FIG. 4 ) oriented toward theeyes of the user in order to triangulate eye vectors and otherinformation. The wearable system 900 may also comprise one or moretextured light projectors (such as infrared (IR) projectors) to injecttexture into a scene.

FIG. 10 is a process flow diagram of an example of a method 1000 fordetermining user input to a wearable system. In this example, the usermay interact with a totem. The user may have multiple totems. Forexample, the user may have designated one totem for a social mediaapplication, another totem for playing games, etc. At block 1010, thewearable system may detect a motion of a totem. The movement of thetotem may be recognized through the outward-facing imaging system or maybe detected through sensors (e.g., haptic glove, image sensors, handtracking devices, eye-tracking cameras, head pose sensors, etc.).

Based at least partly on the detected gesture, eye pose, head pose, orinput through the totem, the wearable system detects a position,orientation, or movement of the totem (or the user's eyes or head orgestures) with respect to a reference frame, at block 1020. Thereference frame may be a set of map points based on which the wearablesystem translates the movement of the totem (or the user) to an actionor command. At block 1030, the user's interaction with the totem ismapped. Based on the mapping of the user interaction with respect to thereference frame 1020, the system determines the user input at block1040.

For example, the user may move a totem or physical object back and forthto signify turning a virtual page and moving on to a next page or movingfrom one user interface (UI) display screen to another UI screen. Asanother example, the user may move their head or eyes to look atdifferent real or virtual objects in the user's FOR. If the user's gazeat a particular real or virtual object is longer than a threshold time,the real or virtual object may be selected as the user input. In someimplementations, the vergence of the user's eyes can be tracked and anaccommodation/vergence model can be used to determine the accommodationstate of the user's eyes, which provides information on a depth plane onwhich the user is focusing. In some implementations, the wearable systemcan use ray casting techniques to determine which real or virtualobjects are along the direction of the user's head pose or eye pose. Invarious implementations, the ray casting techniques can include castingthin, pencil rays with substantially little transverse width or castingrays with substantial transverse width (e.g., cones or frustums).

The user interface may be projected by the display system as describedherein (such as the display 220 in FIG. 2 ). It may also be displayedusing a variety of other techniques such as one or more projectors. Theprojectors may project images onto a physical object such as a canvas ora globe. Interactions with user interface may be tracked using one ormore cameras external to the system or part of the system (such as,e.g., using the inward-facing imaging system 462 or the outward-facingimaging system 464).

FIG. 11 is a process flow diagram of an example of a method 1100 forinteracting with a virtual user interface. The method 1100 may beperformed by the wearable system described herein. Embodiments of themethod 1100 can be used by the wearable system to detect persons ordocuments in the FOV of the wearable system.

At block 1110, the wearable system may identify a particular UI. Thetype of UI may be predetermined by the user. The wearable system mayidentify that a particular UI needs to be populated based on a userinput (e.g., gesture, visual data, audio data, sensory data, directcommand, etc.). The UI can be specific to a security scenario, forexample, where the wearer of the system is observing users who presentdocuments to the wearer (e.g., at a travel checkpoint). At block 1120,the wearable system may generate data for the virtual UI. For example,data associated with the confines, general structure, shape of the UIetc., may be generated. In addition, the wearable system may determinemap coordinates of the user's physical location so that the wearablesystem can display the UI in relation to the user's physical location.For example, if the UI is body centric, the wearable system maydetermine the coordinates of the user's physical stance, head pose, oreye pose such that a ring UI can be displayed around the user or aplanar UI can be displayed on a wall or in front of the user. In thesecurity context described herein, the UI may be displayed as if the UIwere surrounding the traveler who is presenting documents to the wearerof the system, so that the wearer can readily view the UI while lookingat the traveler and the traveler's documents. If the UI is hand centric,the map coordinates of the user's hands may be determined. These mappoints may be derived through data received through the FOV cameras,sensory input, or any other type of collected data.

At block 1130, the wearable system may send the data to the display fromthe cloud or the data may be sent from a local database to the displaycomponents. At block 1140, the UI is displayed to the user based on thesent data. For example, a light field display can project the virtual UIinto one or both of the user's eyes. Once the virtual UI has beencreated, the wearable system may simply wait for a command from the userto generate more virtual content on the virtual UI at block 1150. Forexample, the UI may be a body centric ring around the user's body or thebody of a person in the user's environment (e.g., a traveler). Thewearable system may then wait for the command (a gesture, a head or eyemovement, voice command, input from a user input device, etc.), and ifit is recognized (block 1160), virtual content associated with thecommand may be displayed to the user (block 1170).

Additional examples of wearable systems, UIs, and user experiences (UX)are described in U.S. Patent Publication No. 2015/0016777, which isincorporated by reference herein in its entirety.

Persistent Coordinate Frame(s)

In some embodiments, the wearable system may store one or morepersistent coordinate frames (PCF) within a map database, such as mapdatabase 710. A PCF may be built around points in space in the realworld (e.g. the user's physical environment) that do not change overtime. In some embodiments, a PCF may be built around points in spacethat do not change frequently over time, or are unlikely to change overtime. For example, a point on a building is less likely to changelocation over time than a point on a car since most buildings aredesigned to stay in one location but a car is designed to move peopleand things from one location to another.

A PCF may provide a mechanism to specify locations. In some embodiments,a PCF may be represented as a point with a coordinate system. The PCFcoordinate system may be fixed in the real world and may not change fromsession to session (i.e. when the user turns the system off and then onagain).

In some embodiments, the PCF coordinate system may align with a localcoordinate frame, which may be an arbitrary point in space chosen by thesystem at the beginning of a user session such that the PCF only lastsfor the duration of a session. Such a PCF may be utilized for user posedetermination.

The PCF may be recorded in a map database, such as map database 710. Insome embodiments, the system determines one or more PCFs and stores thePCF in a map, such as a digital map of the real world (which may beimplemented in the systems described herein as a “world mesh”). In someembodiments, the system may choose a PCF by looking for features,points, and/or objects that are invariant over time. In someembodiments, the system may choose a PCF by looking for features,points, objects, etc. that do not change between user sessions on thesystem. The system may utilize one or more computer vision algorithms,optionally in combination with other rule-based algorithms, that lookfor one or more of the features described above. Examples of computervision algorithms are described above in context of object recognition.In some embodiments, the PCF may be a system level determination thatmultiple applications or other system processes may utilize. In someembodiments, the PCF may be determined at the application level.Accordingly, it should be appreciated that a PCF may be represented inany of multiple ways, such as a collection of one or more points orfeatures recognizable in sensor data representing the physical worldaround a wearable system.

World Mesh

3D reconstruction is a 3D computer vision technique that takes images(e.g., colored/gray scale images, depth images, or the like) as inputsand generates 3D meshes (e.g., automatically) representing an observedscene, such as the user's environment and/or the real world. In someembodiments, the 3D mesh representing an observed scene may be called aworld mesh. 3D reconstruction has many applications in virtual reality,mapping, robotics, game, filmmaking, and so forth.

As an example, a 3D reconstruction algorithm can receive input images(e.g., colored/gray scale images, colored/gray scale images+depthimages, or depth-only) and, as appropriate, process the input images toform captured depth maps. For example, passive depth maps can begenerated using multi-view stereo algorithm from colored images, andactive depth maps can be obtained using active sensing technology, suchas a structured-light depth sensor. Although the following example isillustrated, embodiments of the present application may utilize worldmesh that may be generated from any suitable world mesh creation method.One of ordinary skill in the art would recognize many variations,modifications, and alternatives.

FIG. 17 is a simplified flowchart illustrating a method for creating a3D mesh of a scene using multiple frames of captured depth maps.Referring to FIG. 17 , a method to create a 3D model of a scene, forexample, a 3D triangle mesh representing the 3D surfaces associated withthe scene, from multiple frames of captured depth maps is illustrated.The method 1700 includes receiving a set of captured depth maps (1702).A captured depth map is a depth image in which each pixel has anassociated depth value representing the depth from the pixel to thecamera obtaining the depth image. In comparison with a colored imagethat can have three or more channels per pixel (e.g., RGB image withred, green and blue components), a depth map can have a single channelper pixel (i.e., pixel distance from the camera). The process ofreceiving the set of captured depth maps can include processing inputimages, for example, RGB images, to produce one or more captured depthmaps, also referred to as a frame of a captured depth map. In otherembodiments, the captured depth maps are obtained using a time of flightcamera, a LIDAR, stereo cameras, or the like, and are thus received bythe system.

The set of captured depth maps includes depth maps from different cameraangles and/or positions. As an example, a depth map stream can beprovided by a moving depth camera. As the moving depth camera pansand/or moves, the depth maps are produced as a stream of depth images.As another example, a still depth camera could be used to collectmultiple depth maps of portions or all of a scene from different anglesand/or different positions, or combinations thereof.

The method also includes aligning the camera poses associated with setof captured depth maps in a reference frame (1704) and overlaying theset of captured depth maps in the reference frame (1706). In anembodiment, the process of pose estimation is utilized to align thedepth points from all cameras and to create a locally and globallyconsistent point cloud in 3D world coordinates. The depth points fromthe same position in the world coordinate should be aligned as close toeach other as possible. Due to inaccuracy present in the depth maps,however, pose estimation is usually not perfect, especially onstructural features such as the corners of walls, the ends of walls,door frames in indoor scenes, and the like, which cause artifacts onthese structural features when they are present in the generated mesh.Moreover, these inaccuracies can be exacerbated when mesh boundaries areseen as occluders (i.e., objects occluding background objects) becausethe artifacts will be much more noticeable to the user.

In order to align the camera poses, which indicates the position andorientation of the camera associated with each depth image, the depthmaps are overlaid and differences in the positions of adjacent and/oroverlapping pixels are reduced or minimized. Once the positions of thepixels in the reference frame have been adjusted, the camera pose isadjusted and/or updated to align the camera pose with the adjusted pixelpositions. Thus, the camera poses are aligned in the reference frame(1706). In other words, a rendered depth map can be created byprojecting the depth points of all depth maps to the reference frame(e.g., a 3D world coordinate system) based on the estimated cameraposes.

The method further includes performing volumetric fusion (1708) to forma reconstructed 3D mesh (1710). The volumetric fusion process caninclude fusing multiple captured depth maps into a volumetricrepresentation as a discretized version of sign-distance function of theobserved scene. The 3D mesh generation can include the use of themarching cubes algorithm or other suitable method to extract a polygonalmesh from the volumetric representation in the 3D space.

Further details describing methods and systems for creating a 3D mesh ofa real world environment (e.g. world mesh) are provided in U.S.Non-Provisional patent application Ser. No. 15/274,823, entitled“Methods and Systems for Detecting and Combining Structural Features in3D Reconstruction,” which is expressly incorporated herein by referencein its entirety.

User Manipulation Process

FIG. 12 illustrates an example process 1200 of a user interaction usingthe system and methods described herein in which the user may create andsave a scene and then later open that scene. For example, a user may beplaying a game on a AR/VR/MR wearable system, such as wearable system200 and/or 900 described above. The game may enable the user to buildvirtual structures utilizing virtual blocks. The user may spend all daybuilding an elaborate structure, for example, a replica of the user'shouse, and wish to save the structure for later use. The user may wishto ultimately build the user's entire neighborhood or city. If the usersaves the user's house, the user is able to re-open the house andcontinue working on the neighborhood, the next day for example. Sincemany neighborhoods reuse home designs, the user may be able to build andseparately save only five basic designs, and load those designs one ormore times into a single scene in order to build the neighborhood. Theneighborhood scene may then be saved as an additional scene. If the userwishes to continue building, the user may load one or more of theneighborhood scenes, in some embodiments, in combination with one ormore of the five basic home designs, to continue building an entirecity.

The user may choose to save any combination of block designs (i.e. asingle wall, a single house, an entire street of houses, a neighborhood,etc.) for subsequent re-use in future games/designs.

In this example, the user initiates a process of storing a scene byselecting an icon that serves as a control to initiate the captureprocess. At step 1202, the user may select a camera icon. In someembodiments the icon may not be a camera, but could be a differentvisual representation (e.g. text, image, etc.) of a computer program orcode on the system that may create a virtual camera on the system. Forexample, the visual representation could be a word, such as “Camera”,“Start Camera”, or “Take Picture”, or the visual representation could bean image, such as the image of a camera, the image of a picture, theimage of a flower, or the image of a person. Any suitable visualrepresentation may be used.

When the user selects the camera icon, or visual representation of avirtual camera, a virtual camera may appear in the user's environment.The virtual camera may be interacted with by the user. For example, theuser may look through the virtual camera to view real and virtual worldcontent through the camera's FOV, the user may grab the virtual cameraand move the camera around, and/or the user may manipulate the camerathrough a user menu (e.g. to cancel out of the virtual camera, to take apicture, etc.). In some embodiments, the user interactions are asdescribed above, for example in FIGS. 9-11 . In some embodiments, thevirtual camera may provide the same FOV as the user's FOV through thewearable device. In some embodiments, the virtual camera may provide thesame FOV as the user's right eye, the user's left eye, or both of theuser's eyes.

At step 1204, the virtual camera may be operated until it frames ascene. In some embodiments, the camera may frame the scene using atechnique based on user preference, which may specify the manner ofselecting a scene. For example, the frame may initially be the defaultview through the virtual camera viewfinder (i.e. a device or part of acamera showing the field of view of the lens and/or camera system) whenthe virtual camera is first displayed to the user. The viewfinder mayappear to the user as a preview image displayed on the virtual camera,analogous to how many real world digital cameras have a display on theback of the real world camera to preview the image before it iscaptured. In some embodiments, the user may manipulate the camera tochange the frame of the scene. The changed frame may change the previewimage displayed on the virtual camera. For example, the user may selectthe virtual camera by pushing a button on a multi-DOF controller asdescribed above, such as a totem, and move the totem in order to movethe virtual camera. Once the user has the desired view through thevirtual camera, the user may release the button to stop movement of thevirtual camera. The virtual camera may be moved in some or all possibletranslations (e.g., left/right, forward/backward, or up/down) orrotations (e.g., yaw, pitch, or roll). Alternative user interactions maybe used, such as click and release of a button for virtual cameraselection, and a second click and release of a button to release thevirtual camera. Other interactions may be used in order to frame a scenethrough the virtual camera.

The virtual camera may display a preview image to the user during step1204. The preview image may contain virtual content that is within thevirtual camera FOV. Alternatively or additionally, in some embodiments,the preview image may comprise a visual representation of the world meshdata. For example, the user may see a mesh version of a real world couchwithin the virtual camera FOV in the same location as the real couch.The virtual content and mesh data may be spatially correct. For example,if a virtual avatar is seated on the real world couch, then the virtualavatar would appear seated on the mesh couch at the same location,orientation, and/or position. In some embodiments, only the virtualcontent is displayed in the preview image. In some embodiments, thevirtual content is previewed in the same spatial arrangement as thevirtual content is placed in the real world. In some embodiments, thevirtual content is previewed in a different spatial arrangement, such asa cluster, row, circle, or other suitable arrangement.

In some embodiments, the system may automatically frame the scenethrough the virtual camera, for example, to include the greatest numberof virtual objects possible through the viewfinder. Alternate methods ofautomatic scene framing may be used, such as framing the virtual sceneso the user's FOV matches the virtual camera FOV. In some embodiments,the system may automatically frame the scene using a hierarchy ofobjects, so that higher priority objects are within the frame. Forexample, living creatures such as people, dogs, cats, birds, etc. may behigher priority than inanimate objects, such as a table, chair, cup,etc. Other suitable methods may be used to automatically frame the sceneor to create a priority system for automatic framing.

Regardless of how the scene is framed, the system may capture savedscene data. The saved scene data may be used by an augmented realitysystem to render the virtual content of the scene when the saved sceneis later opened. In some embodiments, the saved scene may comprise savedscene objects at spatially fixed locations relative to each other.

In some embodiments, the saved scene data may comprise data that fullyrepresents the saved scene, so the scene may be re-rendered at a latertime and/or at a different location than when and where the scene wassaved. In some embodiments, the saved scene data may comprise datarequired by a system in order to render and display the saved scene tothe user. In some embodiments, the saved scene data comprises a savedPCF, an image of the saved scene, and/or saved scene objects.

In some embodiments, the saved PCF may be the closest PCF to the user,when the saved scene was saved. In some embodiments, the saved PCF maybe a PCF within the framed scene (step 1204). In some embodiments, thesaved PCF may be a PCF within the user's FOV and/or FOR when the scenewas saved. In some embodiments, there may be more than one PCF availableto save. In this case, the system may automatically choose the mostreliable PCF (e.g. the PCF least likely to change over time, per the PCFdescription above). In some embodiments, the saved scene data may havemore than one PCF associated with the saved scene. The saved scene datamay designate a primary PCF, and one or more back-up or secondary PCFs.

In some embodiments, the virtual objects to be saved as part of thescene may be determined based on the objects within the framed scenewhen a scene is saved. Saved scene objects, for example, may be virtualobjects (e.g. digital content) that appear to be located in the user'sreal world environment at the time the scene was saved. In someembodiments, saved scene objects may exclude one or more (up to all)user menus within the saved scene. In some embodiments, the saved sceneobjects comprise all virtual objects within the virtual camera's FOV. Insome embodiments, the saved scene objects comprise all virtual contentthat the user could perceive in the real world within the user's FOR. Insome embodiments, the saved scene objects comprise all virtual contentthat the user may perceive in the real world within the user's FOV. Insome embodiments, the saved scene objects comprise all virtual objectsthat are in the user's environment, regardless of whether the virtualcontent is within the virtual camera's FOV, user's FOV, and/or user'sFOR. In some embodiments, the saved scene objects may comprise anysub-set of virtual objects within the user's environment. The sub-setmay be based on a criteria, such as type of virtual object, for exampleone sub-set may be for building blocks, and a different sub-set may befor landscaping (i.e. plants) around the buildings. An exemplary processfor saving a scene is described below in connection with FIG. 13A.

In addition to storing virtual content and location information, thesystem in step 1206, may capture an image of the framed scene. In someembodiments, the image is captured when the user provides a userinteraction, such as pushing a button on a controller, through agesture, through user head pose, through user eye gaze, and/or any othersuitable user interaction. In some embodiments, the system mayautomatically capture the image. The system may automatically capturethe image when the system has finished automatically framing the scene,as in some embodiments of step 1204. In some embodiments, the system mayautomatically capture the image after the user frames the scene in step1204, for example, by using a timer (e.g. if 5 seconds have passed sincethe user last moved the camera, the system will automatically capturethe image). Other suitable methods of automatic image capture may beused. In some embodiments, storage of the scene may be initiated inresponse to the same events that trigger capture of an image, but thetwo actions may be controlled independently, in some embodiments.

In some embodiments, the captured image may be saved to permanentmemory, such as a hard drive. In some embodiments, the permanent memorymay be the local processing and data module 260, as described above. Insome embodiments, the system may save the scene when the image iscaptured. In some embodiments, the captured image may comprise virtualobjects, world mesh, real world objects, and/or any other content withrenderable data. In some embodiments, the user may wish to save morethan one scene, and hence the process may loop back to step 1202.Further details describing methods and systems related to capturing animage comprising virtual objects and real world objects are provided inU.S. Non-Provisional patent application Ser. No. 15/924,144, (now Pub.No.: US 2018/0268611) entitled “Technique for recording augmentedreality data,” which is expressly incorporated herein by reference inits entirety.

At step 1208, a saved scene icon may be selected. The saved scene iconmay be the framed scene captured in step 1206. In some embodiments, thesaved scene icon may be any suitable visual representation of the savedscene. In some embodiments, the saved scene icon may comprise the imagecaptured in step 1206. For example, the saved scene icon may appear as a3D box with one side of the box comprising the captured image. In someembodiments, the saved scene icon may be one of one or more saved sceneicons. The saved scene icon may be presented in a user menu designed forsaved scene selection.

Once scenes are saved, they may be opened by a user such that thevirtual content of the saved scene appears in the augmented realityenvironment of the user for which the scene was opened. In an exemplaryuser interface to an augmented reality system, a scene may be opened byselecting a saved scene icon in a way that indicates selection of anicon to trigger opening of a scene. The indication may be via userinitiation of a command, such as a LOAD icon, or may be inferred fromcontext, for example. In some embodiments, the user may select a savedscene icon. The user may select the saved scene icon using any suitableuser interaction, such as a click of a button, a gesture, and/or a voicecommand. In some embodiments, the system may automatically select asaved scene icon. For example, the system may automatically select asaved scene icon based on user location. The system may automaticallyselect a saved scene icon that corresponds to a saved scene that waspreviously saved in the room where the user is currently located. Insome embodiments, the system may automatically select a saved scene iconbased on context. For example, if the user saved a scene at school, thesystem may automatically select the saved scene if the user is at anyeducational setting.

FIG. 12 includes steps for selecting and opening a saved scene. At step1210, the saved scene icon is moved from its default location. In someembodiments, the saved scene icon is located within a saved scene usermenu which may contain one or more saved scene icons that represent oneor more saved scenes. In some embodiments, the saved scene icon is notlocated in a saved scene user menu, and is instead an isolated icon. Forexample, the saved scene icon may be automatically placed within thesaved scene. As a specific example, the saved scene icon may beautomatically placed at the saved PCF location or at the location theuser was when the scene was saved.

At step 1212, the saved scene icon may be placed in the user'senvironment. In some embodiments, the user may select a saved scene iconfrom a saved scene user menu 1208 by pressing a button on a multi-DOFcontroller, for example. By moving the controller, the user can thenpull the saved scene icon out of the user menu 1210 and then place thesaved scene icon 1212 by releasing the button on the multi-DOFcontroller. In some embodiments, the user may select a saved scene iconfrom its default saved PCF location 1208 by pressing a button on amulti-DOF controller, for example. The user may then move the savedscene icon out of the default saved PCF location 1210 and then place thesaved scene icon 1212, for example closer to the user's currentlocation, by releasing the button on the multi-DOF controller. In someembodiments, the system may automatically place the saved scene icon1212. For example, the system may automatically move the saved sceneicon to a fixed distance from the user, or may automatically place thesaved scene icon relative to a multi-DOF controller, such as at the tipof a totem. In some embodiments, the system may automatically place thesaved scene icon at a fixed location relative to a user's hand if aparticular gesture is performed, such as a pinch or point gesture, forexample. Any other suitable method may be used to place the saved sceneicon 1212, whether the placement is automatically performed by thesystem or by the user.

After step 1212, the saved scene icon may be instantiated 1220 into acopy of the original scene, or the saved scene icon may be furthermanipulated by steps 1214-1218.

At step 1214, the user may select a position of a visual anchor nodeindicating where the saved scene is to be opened. Once the visual anchornode is selected, when the saved scene is opened, the system may rendervirtual content of the saved scene with the saved scene anchor nodealigned with the visual anchor node, such that the virtual contentappears with the same spatial relationship with respect to the visualanchor node as it has to the saved scene anchor node. In someembodiments, the saved scene icon may indicate the location of thevisual anchor node. In some embodiments, the saved scene icon may changeits visual representation after being placed 1212 to comprise a visualanchor node which was previously not visible to the user. In someembodiments, the saved scene icon may be replaced with a differentvisual representation of a visual anchor node. In some embodiments, thesaved scene icon and the visual anchor node are the same. In someembodiments, the visual anchor node may be a separate icon from thesaved scene icon, providing a visual representation of the saved sceneanchor node.

The saved scene anchor node may be the root node that all saved sceneobjects are placed relative to in order to maintain consistent spatialrelativity between saved scene objects within a saved scene. In someembodiments, the saved scene anchor node is the highest node in thesaved scene hierarchy of nodes that represent at least a portion of thesaved scene data. In some embodiments, the saved scene anchor node isthe anchor node in a hierarchical structure that represents at least aportion of the saved scene data. In some embodiments, the saved sceneanchor node may act as a reference point for placing the saved sceneobjects relative to each other. In some embodiments, the saved sceneanchor node may represent a scenegraph for the saved scene objects.

Regardless of how the visual anchor node appears to the user, the usermay through the user interface, instruct the system to set the locationof the visual anchor node. At step 1216, the user may move the visualanchor node. In some embodiments, when the visual anchor node is moved,the virtual scene objects move with the visual anchor node. In someembodiments, the visual anchor node is a visual representation of thesaved scene anchor node. In some embodiments, the visual anchor node mayprovide a point and coordinate system with which to manipulate the savedscene anchor node location and orientation. In some embodiments, movingthe visual anchor node 1216 may mean translation, rotation, and/or 6DOFmovement.

In step 1218, the user may place the visual anchor node. In someembodiments, the user may select the visual anchor node 1214 by pushinga button on a totem, for example. The user may then move the visualanchor node 1216 within the user's real world environment and then placethe visual anchor node 1218 by releasing the button on the totem, forexample. Moving the visual anchor node moves the entire saved scenerelative to the user's real world. Steps 1214-1218 may function to moveall of the saved scene objects within the user's real world. Once thesaved scene is at the desired location, the saved scene may beinstantiated 1220. At step 1220, instantiating the saved scene may meana full copy of the saved scene is presented to the user. However, itshould be appreciated that the virtual content of the saved scene may bepresented with the same physics and other characteristics as othervirtual content rendered by the augmented reality system. Virtualcontent that is occluded by physical objects in the location where thesaved scene is opened may not be visible to the user. Likewise, when theposition of the virtual content, as determined by its position withrespect to the visual scene anchor node, may be outside the users FOVand likewise may not be visible at the time of opening the scene. Theaugmented reality system may nonetheless have information about thisvirtual content available for rendering it, which may occur when theuser's pose or environment changes such that this virtual contentbecomes visible to the user.

After step 1220, the process may repeat starting at step 1208. This loopmay enable the user to load more than one saved scene at a time into theuser's environment.

In one exemplary embodiment, process 1200 starts with a user that hasalready assembled one or more component virtual object pieces into ascene, such as the user building a replica of the user's house out ofcomponent (e.g. pre-designed, pre-loaded, provided as manipulatableobjects from the application) virtual building blocks. The user thenselects the camera icon 1202, frames a scene 1204 to help the userremember what the scene comprises, and then the user presses a button tocapture the image 1206 of the replica of the user's house. At this pointthe replica of the user's house is saved to the system and a saved sceneicon corresponding to the replica of the user's house may be displayedto the user in a saved scene user menu. The user may turn off thesystem, go to bed for the night, and then resume building the next day.The user may select the saved scene icon 1208 that corresponds to thereplica of the user's house from the saved scene user menu by clicking abutton on a totem, pulling the saved scene out of the saved scene usermenu 1210, and then placing the saved scene icon 1212 in front of theuser by dragging the saved scene icon to the desired location andreleasing the button on the totem. A preview of the saved scene objectsmay automatically appear to the user, with a visual anchor nodecentrally located relative to the saved scene objects. The preview mayappear as a white-washed, spatially correct, visual-only copy of thesaved scene. The user may decide to change where the saved scene islocated based on the preview, and may thus select the visual anchor node1214 by clicking a button on the totem, move the visual anchor node 1216(which may cause all of the saved scene objects to move with the visualanchor node to maintain relative positioning to the visual anchor nodeand internally between the saved scene objects) by moving the totem, andthen placing the visual anchor node 1218 at a different location in theuser's environment by releasing the button on the totem. The user maythen select a “load scene” virtual button from a user menu, which maycause the saved scene to instantiate 1220 and thus fully load thevirtual scene by rendering the full saved scene data (e.g. an exact copyof the original scene, except potentially in a different location thanwhere it was saved).

Process for Saving a Scene

FIG. 13A illustrates an example process 1300 a for saving a scene usingthe system and methods described herein. The process 1300 a may startwith an application already open and running on a AR/VR/MR wearablesystem, such as wearable system 200 and/or 900 described above, that mayenable a user to place one or more pre-designed virtual objects into theuser's real world environment. The user's environment may already bemeshed (e.g. the world mesh available to the application is alreadycreated). In some embodiments, the world mesh may be an input to a mapdatabase, such as the map database 710 from FIG. 7 and/or FIG. 8 forexample. The world mesh may be combined with world mesh from otherusers, or from the same user from different sessions and/or over time,to form a larger world mesh stored in the map database. The larger worldmesh may be called the passable world, and may comprise mesh data fromthe real world in addition to object tags, location tags, and the like.In some embodiments, the meshed real world environment available to theapplication may be any size, and may be determined by the processingcapabilities of the wearable system (may not exceed a maximum allocatedcompute resource allocated to the application). In some embodiments, themeshed real world environment (world mesh) available to the applicationmay have a 15 foot by 15 foot footprint with a ten foot height. In someembodiments, the world mesh available to the application may be the sizeof the room or building the user is located in. In some embodiments, theworld mesh size and shape available to the application may be the first300 square feet meshed by the wearable system when the application isfirst opened. In some embodiments, the mesh available to the applicationis the first area or volume meshed until a maximum threshold has beenmet. Any other surface area or volumetric measure may be used, in anyquantity, as long as the wearable system has the compute resourcesavailable. The shape of the world mesh available to the application maybe any shape. In some embodiments, a surface area may be defined for theworld mesh available to the application and could be the shape of asquare, rectangle, circle, polygon, etc., and may be one continuous areaor may be two or more disconnected areas (as long as the total does notexceed the maximum surface area threshold, for example). In someembodiments, a volume may be defined for the world mesh available to theapplication, and may be a cube, sphere, torus, cylinder, cuboid, cone,pyramid, prism, etc., and may be continuous volume or may be two or moredisconnected volumes (as long as the total does not exceed the maximumvolume threshold, for example).

Example process 1300 a may begin at step 1202 when a camera icon isselected, as described for FIG. 12 . Step 1202 may cause the system toplace a virtual render camera into a virtual render scene 1304. Thevirtual render scene may be a digital representation, created bymanipulation of data on one or more processors (such as processingmodules 260 or 270 or remote data repository 280 or wearable system 200,for example), of all renderable virtual content available to the user.One or more virtual render cameras may be placed in the virtual renderscene. The virtual render cameras may function similar to real worldcameras in that the virtual render camera has a location and orientationin (virtual render world) space and may capture a 2D image of a 3D scenefrom that location and orientation.

The virtual render camera may act as an input for a render pipeline forthe wearable system, with the location and orientation of the virtualrender camera defining portion of the user's environment, includingvirtual content present in that portion of the environment that will berendered to the user as an indication of what the render camera is beingpointed at. The render pipeline may comprise one or more processesrequired in order for the wearable system to convert digital data intovirtual content ready for display to the user. In some embodiments,rendering for the wearable system may occur in a render engine, whichmay be located in a graphics processing unit (GPU), which may be part ofor connected to the processing modules 160 and/or 270. In someembodiments, the render engine may be a software module in a GPU thatmay provide images to display 220. In some embodiments, the virtualrender camera may be placed in the virtual render scene at a positionand orientation such that the virtual render camera has the sameperspective and/or FOV as the default view through the virtual cameraviewfinder, as described in context of FIG. 12 .

In some embodiments, a “virtual render camera,” which is sometimes alsoreferred to as a “render camera”, “pinhole perspective camera” (orsimply “perspective camera”) or “virtual pinhole camera”, is a simulatedcamera for use in rendering virtual image content possibly from adatabase of objects in a virtual world. The objects may have locationsand orientations relative to the user or wearer and possibly relative toreal objects in the environment surrounding the user or wearer. In otherwords, the render camera may represent a perspective within render spacefrom which the user or wearer is to view 3D virtual contents of thevirtual render world space (e.g., virtual objects). The user may viewthe render camera perspective by viewing a 2D image captured from thevirtual render camera's perspective. The render camera may be managed bya render engine to render virtual images based on the database ofvirtual objects to be presented to said eye. The virtual images may berendered as if taken from the perspective of the user or wearer, fromthe perspective of the virtual camera that may frame the scene in step1204, or from any other desired perspective. For example, the virtualimages may be rendered as if captured by a pinhole camera (correspondingto the “render camera”) having a specific set of intrinsic parameters(e.g., focal length, camera pixel size, principal point coordinates,skew/distortion parameters, etc.), and a specific set of extrinsicparameters (e.g., translational components and rotational componentsrelative to the virtual world). The virtual images are taken from theperspective of such a camera having a position and orientation of therender camera (e.g., extrinsic parameters of the render camera).

The system may define and/or adjust intrinsic and extrinsic rendercamera parameters. For example, the system may define a particular setof extrinsic render camera parameters such that virtual images may berendered as if captured from the perspective of a camera having aspecific location with respect to the user's or wearer's eye so as toprovide images that appear to be from the perspective of the user orwearer. The system may later dynamically adjust extrinsic render cameraparameters on-the-fly so as to maintain registration with said specificlocation, as used for eye tracking for example. Similarly, intrinsicrender camera parameters may be defined and dynamically adjusted overtime. In some implementations, the images are rendered as if capturedfrom the perspective of a camera having an aperture (e.g., pinhole) at aspecific location with respect to the user's or wearer's eye (such asthe center of perspective or center of rotation, or elsewhere).

Further details describing methods and systems related to renderpipelines and render cameras are provided in U.S. Non-Provisional patentapplication Ser. No. 15/274,823, entitled “Methods and Systems forDetecting and Combining Structural Features in 3D Reconstruction,” andU.S. Non-Provisional patent application Ser. No. 15/683,677, entitled“Virtual, augmented, and mixed reality systems and methods,” which isexpressly incorporated herein by reference in its entirety.

At step 1306, the system may render the framed scene 1306, as framed instep 1204. In some embodiments, the system may render the framed sceneat a regular refresh rate defined by the system, when the locationand/or orientation of the virtual camera changes during scene framing1204, or at any other suitable time. In some embodiments, as the virtualcamera moves during step 1204, the virtual render camera moves withcorresponding movement within the virtual render scene to maintain aperspective corresponding to the virtual camera perspective. In someembodiments, the virtual render camera may request all renderable dataavailable to the virtual render camera be sent to the render pipeline.Renderable data may be the collection of data required by the wearablesystem in order to display virtual content to the user. Renderable datamay be the collection of data required by the wearable system in orderto render virtual content. The renderable data may represent the virtualcontent in the field of view of the virtual render camera. Alternativelyor additionally, the renderable data may include data representingobjects in the physical world, extracted from images of the physicalworld acquired with sensors of a wearable system and converted into aformat that can be rendered.

For example, raw world mesh data, which may be generated from imagescollected with cameras of a wearable augmented reality system, may notbe renderable. Raw world mesh data may be a collection of vertices, andthus not data that can be displayed to the user as a 3D object orsurface. Raw world mesh data in raw text format may comprise a vertexcomprising three points (x, y, and z) relative to the location of thevirtual camera (and virtual render camera since their perspectives aresynchronized). Raw world mesh data in raw text format, for example, mayalso comprise data representing the other nodes, or vertices, eachvertex is connected to. Each vertex may be connected to one or moreother vertices. In some embodiments, world mesh data may be thought ofas a location in space and data specifying the other nodes the vertex isconnected to. The vertex and connecting vertex data in the raw worldmesh data may be subsequently used to build out polygons, surfaces, andhence a mesh, but would require additional data to make the raw worldmesh data renderable. For example, a shader, or any other programcapable of performing the same function, may be used to visualize theraw world mesh data. The program may follow a set of rules toautomatically, computationally visualize the raw world mesh data. Theshader may be programmed to draw a dot at each vertex location, and thendraw a line between each vertex and the set of vertices connected to thevertex. The shader may be programmed to visualize the data in one ormore colors, patterns, etc. (e.g. blue, green, rainbow, checkered,etc.). In some embodiments, the shader is a program designed toillustrate the points and connections of the world mesh data. In someembodiments, the shader may connect lines and dots to create surfaces onwhich a texture, or other visual manifestation may be added. In someembodiments, renderable world mesh data may comprise UV data such as UVcoordinates. In some embodiments, the renderable world mesh data maycomprise a depth check to determine overlap or obstructions betweenvertices within the raw world mesh data, or the depth check mayalternatively be performed within the render pipeline as a separateprocess. In some embodiments, applying a shader and/or other processesto visualize raw world mesh data enables the user to visualize, andsubsequently view, what is typically non-visual data. In someembodiments, other raw data or traditionally non-visual data may beconverted to renderable data using the process described for the rawworld mesh data. For example, anything that has a location in space maybe visualized, for example by applying a shader. In some embodiments,PCFs may be visualized, such as by providing data defining an icon thatcan is positioned and oriented like the PCF.

Another example of renderable data (e.g. renderable 3D data, 3Drenderable digital object), is data for a 3D virtual object, such as acharacter in a video game, a virtual avatar, or the building blocks usedto build a replica of the user's house, as described for FIG. 12 .Renderable data for a 3D virtual object may comprise mesh data and meshrenderer data. In some embodiments, mesh data may comprise one or moreof vertex data, normal data, UV data, and/or triangle indices data. Insome embodiments, mesh renderer data may comprise one or more texturedata sets, and one or more properties (such as material properties, suchas shininess, specular level, roughness, diffuse color, ambient color,specular color, etc., for example).

In some embodiments, the virtual render cameras may have settings thatdetermine a sub-set of the renderable data to be rendered. For example,the virtual render camera may be capable of rendering three sets ofrenderable data: virtual objects, world meshes, and PCFs. The virtualcamera may be set to render only virtual objects, only world mesh, onlyPCFs, or any combination of those three sets of renderable data. In someembodiments, there may be any number of sub-sets of renderable data. Insome embodiments, setting a virtual render camera to render world meshdata with virtual object data may enable the user to see traditionalvisual data (3D virtual object, for example) superimposed ontraditionally non-visual data (raw world mesh data, for example).

FIG. 13B illustrates an example process 1300 b for rendering a framedscene using the system and methods described herein. Process 1300 b maydescribe step 1306 in more detail. Process 1300 b for rendering a framedscene may begin at step 1318 request renderable data. In someembodiments, the virtual render camera, that may correspond to thevirtual camera of FIG. 12 , requests renderable data for all renderableobjects located within the virtual render camera's FOV within thevirtual render scene. In some embodiments, the virtual render camera mayonly request the renderable data for objects the virtual render camerahas been programmed to request. For example, the virtual render cameramay only be programmed to request renderable data for 3D virtualobjects. In some embodiments, the virtual render camera may requestrenderable data for 3D virtual objects and renderable data for worldmesh data.

At step 1320, the renderable data is sent to the render pipeline 1320.In some embodiments, the render pipeline may be the render pipeline forthe wearable system, such as wearable system 200. In other embodiments,the render pipeline may be located on a different device, on a differentcomputer, or performed remotely. At step 1322, the rendered scene iscreated. In some embodiments, the rendered scene may be the output ofthe render pipeline. In some embodiments, the rendered scene may be a 2Dimage of a 3D scene. In some embodiments, the rendered scene may bedisplayed to the user. In some embodiments, the rendered scene maycomprise scene data ready to be displayed, but not actually displayed.

In some embodiments, the system renders the framed scene and displaysthe rendered scene to the user through the virtual camera viewfinder.This may enable the user to view the framed scene, even as the virtualcamera is moving, to preview the 2D image that would be captured if thecapture image step 1206 was performed at that point in time. In someembodiments, the rendered scene may comprise visual and non-visualrenderable data.

After step 1204, the user may choose to capture the image 1206 or selectcancel 1302 to cancel the scene saving process 1300 a. In someembodiments, step 1302 may be performed by the user. In someembodiments, step 1302 may be performed automatically by the system. Forexample, if the system is unable to automatically frame the scene instep 1204 to the specifications programmed (for example to capture allof the virtual objects within the frame), then the system mayautomatically cancel at step 1302 the scene saving process 1300 a. Ifcancel is selected in step 1302, the system removes the virtual rendercamera corresponding to the virtual camera, from process 1200 forexample, from the virtual render scene 1308.

If the image is captured at step 1206, the system captures a 2D image1310. In some embodiments, the system captures a 2D image by taking apicture (storing data representing the 2D image being rendered)utilizing the virtual render camera within the virtual render scene. Insome embodiments, the virtual render camera may function analogously toa real world camera. The virtual render camera may convert 3D scene datato a 2D image by capturing the projection of the 3D scene onto a 2Dimage plane from the virtual render camera's perspective. In someembodiments, the 3D scene data is captured as pixel information. In someembodiments, the virtual render camera is not analogous to a real worldcamera because the virtual render camera may be programmed to captureanywhere between one and all sub-sets of renderable data, whereas a realworld camera captures everything that is present in the view. The 2Dimage captured in step 1310 may comprise only the sub-set(s) ofrenderable data that the camera is programmed to capture. The sub-setsof renderable data may comprise traditional visual data, such as 3Dobjects, and/or traditional non-visual data, such as world mesh or PCFs.

At step 1312 and 1314, the system saves the scene. Saving the scene mayentail saving any or all of the types of saved scene data as describedabove, such as data representing the virtual content being rendered bythe virtual render camera and, in some embodiments, positioninformation. At step 1312, the system binds the scene to the nearestPCF. The application may send a request for the PCF ID to a lower levelsystem operation that manages the list of PCFs and their correspondinglocations. The lower level system operation may manage the map database,which may comprise the PCF data. In some embodiments, the PCFs aremanaged by a separate PCF application. The PCF bound to the scene may becalled the saved PCF.

At step 1314, the system writes saved scene data to permanent memory ofthe wearable system. In some embodiments, the permanent memory may be ahard drive. In some embodiments, the permanent memory may be the localprocessing and data module 260, as described above. In some embodiments,the saved scene data may comprise data that fully represents the savedscene. In some embodiments, the saved scene data may comprise datarequired by a system in order to render and display the saved scene tothe user. In some embodiments, the saved scene data comprises a savedPCF, an image of the saved scene, and/or saved scene objects. The savedscene objects may be represented by saved scene object data. In someembodiments, the saved scene object data may comprise a tag for whatkind of object it is. In embodiments in which the saved scene object isderived by modifying a pre-designed base object, the saved scene objectdata may also indicate differences between the saved scene object andthe pre-designed base object. In some embodiments, the saved sceneobject data may comprise a pre-designed base object name plus additionalproperties and/or state data. In some embodiments, the saved sceneobject data may comprise the renderable mesh plus state, physics, andother properties that may be required in order for the saved sceneobject to re-load as a copy of how it was saved.

At step 1316, the system may add a saved scene icon to a user menu. Thesaved scene icon may be a visual representation for the saved scene, andmay optionally comprise the 2D image captured in step 1310. The savedscene icon may be placed in a user menu, for example a saved scene usermenu. The saved scene user menu may contain one or more saved scenes foran application.

Process for Loading a Saved Scene

FIG. 14 illustrates an example process 1400 for loading a scene usingthe system and methods described herein. The process 1400 may start atstep 1402, where the user opens a user menu. The user menu may compriseone or more saved scene icons, which may represent one or more savedscenes. In some embodiments, the user menu may be a saved scene usermenu. In response to step 1402, the system may perform a PCF check 1422.The PCF check may comprise one or more processes that determines the PCFclosest to the user's current position (current PCF). In someembodiments, the application may determine the user's location. In someembodiments, the location may be based on the user's headpose location.

If the saved PCF matches the current PCF, then the saved scene may beplaced in a current PCF section of the user menu 1424. If the saved PCFdoes not match the current PCF, then the saved scene may be placed inthe other PCF section in the user menu. In some embodiments, steps 1424and 1426 may be combined, for example if the user menu does notcategorize the saved scenes based on the user's current location, or ifthe user's current PCF cannot be determined. At this point in process1400, the user may view a saved scene user menu. In some embodiments,the user menu is separated into two sections—one section for savedscenes that have saved PCFs matching the current PCF, and a secondsection for saved scenes that have saved PCFs not matching the currentPCF. In some embodiments, one of the two sections may be empty.

At step 1404, the user may select a saved scene icon from the user menu.The user menu may comprise a saved scene user menu. In some embodiments,the user may select the saved scene icon through a user interaction,such as a click of a button on a totem or other user controller.

At step 1406, the user may take an action indicating that the content ofthe virtual content of the selected saved scene is to be loaded into theenvironment of the user for which the saved scene is to be opened. Forexample, the user may remove the saved scene icon from the user menu1406. In some embodiments, step 1406 may occur as the user holds downthe button used to select the saved scene icon. Step 1428 may occur as aresult of step 1406. When the saved scene icon is removed from the usermenu 1406, the system may load the saved scene (or saved scene data) tovolatile memory from a hard drive or other permanent memory 1428.

A location in the environment for the saved scene content may also bedetermined. In the illustrated embodiment, when the saved scene isopened in the same location at which it was saved, the system maydisplay the visual content of the saved scene in the same location thatit appeared at the time the scene was saved. Alternatively, if the savedscene is opened in a different location, an alternative approach, suchas receiving user input as described below in connection with steps 416,1418 and 1420, may be used.

To support opening the saved scene with objects in the same location aswhen the scene was stored, at step 1430, the system may perform a PCFcheck. The PCF check may comprise one or more processes that determinesthe PCF closest to the user's current position (current PCF). In someembodiments or process 1400, either PCF check 1422 or PCF check 1430 maybe performed instead of both. In some embodiments, additional PCF checksmay be added to process 1400. The PCF checks may occur at a fixed timeinterval (e.g. once per minute, once per second, once every fiveminutes, etc.), or may be based on a change in location of the user(e.g. if user movement is detected, the system may add an additional PCFcheck).

At step 1432, if the saved PCF matches the current PCF, then the savedscene objects are preview placed relative to the PCF. In someembodiments, preview placed may comprise rendering only the visual dataassociated with the saved scene data. In some embodiments, previewplaced may comprise rendering the visual data associated with the savedscene data, in combination with one or more shaders to alter theappearance of the visual data and/or additional visual data. An exampleof additional visual data may be one or more lines that extend from thevisual anchor node to each of the saved scene objects. In someembodiments, the user may be involved in performing step 1432, such asby providing input indicating locations of the saved scene objects. Insome embodiments, the system may automatically perform step 1432. Forexample, the system may automatically perform step 1432 by calculatingthe location at the center of the saved scene objects and then placingthe visual anchor node at the center.

At step 1434, if the saved PCF does not match the current PCF, then thesaved scene objects are preview placed relative to a visual anchor node.In some embodiments, the relative placement may be placing the savedscene objects such that the visual anchor node in the center of thesaved scene objects. Alternatively, the saved scene objects may bepositioned to have the same spatial relationship with respect to thevisual anchor node that those objects have with respect to a saved sceneanchor node. n some embodiments, the placement may be determined byplacing the visual anchor node at a fixed distance away from the user(e.g. 2 feet away from the user in the z-direction at eye level). Insome embodiments, the user may be involved in performing step 1434, suchas by providing input indicating the location of the visual anchor node.In some embodiments, the system may automatically perform step 1434. Forexample, the system may automatically perform step 1434 by automaticallyplacing the visual anchor node at a fixed distance from the user menu ormay select a location of the visual anchor node relative to a locationof a physical or virtual object in the environment of the user for whomthe saved scene is to be loaded.

At step 1436, the system may display a user prompt to the user to eithercancel or instantiate the saved scene. The user prompt may have anysuitable visual appearance, and may function to enable one or more userinteractions in order to at least cause the system to either cancelre-opening the scene (e.g. process does not proceed to 1440) and/orinstantiate the scene. In some embodiments, the user prompt may displayone or more interactable virtual objects, such as a button labeled“cancel” or “load scene”, for example.

In some embodiments, the system may display the saved scene preview assoon as the saved scene icon is removed from the user menu at step 1406such that the user may be able to view the preview upon moving the icon.At step 1408, the user may release the saved scene icon to place thesaved scene icon in the user's real world environment. At step 1410, theuser may be able to view the saved scene preview and the user prompt toeither cancel the saved scene load or to instantiate the scene. In someembodiments, a saved scene preview may comprise only the visual dataassociated with the saved scene, optionally with the visual datamodified. In some embodiments, the visual data may appear white-washed.In some embodiments, the saved scene preview may appear as a ghostpreview of the visual data corresponding to the saved scene data. Insome embodiments, the saved scene preview may appear as a hollow copy ofthe data, where the preview looks recognizably similar to the savedseem, but may not have the same functionality or sound. In someembodiments, the saved scene preview may be the visual datacorresponding to the saved scene data without state data or physicsapplied.

At step 1412, the user may select cancel. Step 1412 may cause the systemto stop displaying content and remove the saved scene from volatilememory 1438. In some embodiments, the system may only stop displayingthe saved scene content, but may keep the saved scene in volatilememory. In some embodiments, the content may comprise all or part of thesaved scene data, user menus, user prompts, or any other virtual contentthat may be specific to the saved scene selected in step 1404.

At step 1414, the user may select to instantiate the saved scene. Insome embodiments, this may be the same as step 1220. In someembodiments, step 1414 may fully load the virtual scene by rendering thefull saved scene data (e.g. an exact copy of the original scene, exceptpotentially in a different location than where it was saved). In someembodiments, the instantiation may comprise applying physics and statedata to the visual preview.

At step 1416, the user may select the visual anchor node. At step 1418,the user may move the visual anchor node. This may cause the system tomove the saved scene parent node location to match the visual anchornode location 1442. In some embodiments, the visual anchor node locationmay be moved without modifying anything else in the saved scene data.This may be achieved by placing the saved scene objects relative to thevisual anchor node in a manner that preserves the spatial relationshipsbetween saved scene objects and the saved scene anchor node, regardlessof where that visual anchor node may be located. In some embodiments,the process may loop back to step 1436 after step 1442.

At step 1420, the user may release the visual anchor node, indicatingthe location of the visual anchor node. The process may loop back tostep 1410 after step 1420, where the user once again has the option tocancel the saved scene load 1412, instantiate the saved scene 1414, ormove the visual anchor node 1416-1420 (and hence entire saved sceneobjects, which remain spatially consistent to each other).

In some embodiments, the system may perform one or more of the steps1402-1420, described as involving user interaction with the system,partially or totally automatically. In one illustrative example of thesystem automatically performing steps 1402-1420, the system mayautomatically open a user menu 1402 when the current PCF matches a savedPCF. The system may have the PCF check process running the entire timethe application is running, or the system may refresh the PCF check atfixed intervals (e.g. every 1 minute), or the system may run the PCFcheck if the system detects a change (e.g. user movement). At step 1402,the system may automatically select a saved scene if there is only onesaved scene with a saved PCF that matches the current PCF. At step 1406,the system may automatically remove the saved scene icon from the usermenu if the current PCF matches the saved PCF for more than a thresholdperiod of time (e.g. five minutes). At step 1408, the system mayautomatically release the saved scene icon at a fixed distance from theuser (e.g. 1 foot to the right of the user, in the x-direction). At step1412, the system may automatically cancel out of process 1400 if theuser leaves the room, thus causing the saved PCF to no longer match thecurrent PCF. At step 1414, the system may automatically instantiate thesaved scene if the current PCF matches the saved PCF for greater than athreshold period of time. The system may perform steps 1416-1420automatically by moving the visual anchor node to maintain a fixedrelative spatial relationship to the user while the user moves (e.g.visual anchor node is fixed to 2 feet in front of the user in thez-direction).

Process for Loading a Saved Scene—Shared Path

FIG. 15 illustrates an example process 1500 for loading a scene usingthe system and methods described herein. At step 1502, a saved sceneicon may be selected. In some embodiments, the user may select the savedscene icon. In some embodiments, the saved scene icon may be selectedfrom a user menu, or may be selected as a stand alone icon placed in theuser's real world environment. In some embodiments, the saved scene iconmay be automatically selected by the wearable system and/or theapplication. For example, the system may automatically select the savedscene icon that is closest to the user, or the system may automaticallyselect the saved scene icon that is most frequently used regardless oflocation.

At step 1504, the saved scene icon is moved from its default location.In some embodiments, the user may remove the saved scene icon from auser menu, as described in step 1406 in process 1400. In someembodiments, the system may automatically move the saved scene icon fromits default position (e.g. in a user menu, or at a placed location inthe user's environment). For example, the system may automatically movethe saved scene icon to maintain a fixed distance from the user.

The system may determine a location for saved scene objects in theenvironment of the user for whom the saved scene is being opened. Insome embodiments, the system may display a visual anchor node to theuser and may enable the user to impact the location at which the savedscene objects are placed by inputting commands that move the location ofthe visual anchor node and/or the positioning of saved scene objectswith respect to the visual anchor node. In some embodiments, the savedscene objects may each have a position with respect to a saved sceneanchor node, and the saved scene objects may be positioned such thatthey have that same relative position to the visual anchor node, thuspositioning the saved scene anchor node at the visual anchor node.

In other embodiments, user input may specify a spatial relationshipbetween one or more saved scene objects and the visual anchor node. Atstep 1506, the visual anchor node may be placed relative to the savedscene objects. Placing the visual anchor node relative to the savedscene objects may function to tie a particular location to the savedscene anchor. The choice of visual anchor location may impact therelative level of ease or difficulty with which the saved scene mayfurther be manipulated, for example to later place the saved sceneobjects relative to the environment. In some embodiments, the visualanchor node may be placed relative to the saved scene objects byreleasing a button on a totem (if the user pressed a button to selectand move the saved scene icon, for example). In some embodiments, theuser may choose where to place the visual anchor node in relation to thesaved scene objects. For example, the user may choose to place thevisual anchor node in close proximity to a particular saved sceneobject. The user may choose to do this if the user only cares where thatparticular object is placed. In some embodiments, the user may wish toplace the visual anchor node in a particular location that makes it easyto further manipulate the visual anchor node.

At step 1508, the saved scene objects may be preview placed relative tothe real world. In some embodiments, the saved scene objects may bepreview placed relative to the real world by moving the visual anchornode. Moving the visual anchor node may cause all of the saved sceneobjects to move with the visual anchor node, thus maintaining a fixedrelative spatial configuration between the saved scene objects within asaved scene. In some embodiments, moving the visual anchor node maychange the anchor node location to match the current visual anchor nodelocation. In some embodiments, the user may manipulate the visual anchornode to place the saved scene in the desired location relative to theuser's environment. In some embodiments, the system may automaticallypreview place the saved scene objects relative to the real world. Forexample, the objects of the saved scene may have been, at the time thesaved scene was stored, positioned with respect to a surface. Toposition the saved scene objects upon opening the saved scene, thesystem may find the closest surface that has similar attributes and/oraffordances to the surface on which the virtual objects were positionedwhen saved. Examples of affordances may include, surface orientation(e.g. vertical surface, horizontal surface), object type (e.g. table,couch, etc.), or relative height from the ground surface (e.g. low,medium, high height categories). Additional types of attributes oraffordances may be used. In some embodiments, the system mayautomatically preview place an object in the real world on the nextclosest meshed surface.

An affordance may comprise a relationship between the object and theenvironment of the object which may afford an opportunity for an actionor use associated with the object. The affordance may be determinedbased on, for example, the function, the orientation, the type, thelocation, the shape, or the size of the virtual object or thedestination object. The affordances may also be based on the environmentin which the virtual object or the destination object is located. Theaffordance of a virtual object may be programmed as part of the virtualobject and stored in the remote data repository 280. For example, thevirtual object may be programmed to include a vector which indicates thenormal of the virtual object.

For example, an affordance of a virtual display screen (e.g., a virtualTV) is that the display screen can be viewed from a direction indicatedby a normal to the screen. An affordance of a vertical wall is thatobjects can be placed on the wall (e.g., “hang” on the wall) with theirsurface normal parallel to a normal to the wall. An additionalaffordance of the virtual display and the wall can be that each has atop or a bottom. The affordances associated with an object may helpensure the object has more realistic interactions, such as automaticallyhanging the virtual TV right side up on a vertical surface.

Automatic placement of virtual objects by the wearable system, utilizingaffordances, is described in U.S. Patent Publication No. 2018/0045963,published Feb. 15, 2018, which is incorporated by reference herein inits entirety.

At step 1510, the preview placed saved scene objects may be movedrelative to the real world. In some embodiments, this may beaccomplished by moving the visual anchor node. For example, the user mayselect the visual anchor node by performing a pinch gesture, may movethe visual anchor node while maintaining the pinch gesture until thedesired location has been reached, and then the user may stop themovement and release the pinch gesture. In some embodiments, the systemmay automatically move the saved scene relative to the real world.

At step 1512, the saved scene may be instantiated. Instantiating thescene may comprise applying the full saved scene data to the saved sceneobjects, as opposed to only applying the preview version of the savedscene. For example, the preview of the saved scene may involve onlydisplaying the visual data, or a modified version of the visual data.Step 1512 may instead display the visual data as saved in the savedscene data, plus the rest of the data (e.g. physics), with the exceptionof the saved scene potentially having a new anchor node location.

Process for Loading a Saved Scene—Split Path

FIG. 16 illustrates an example process 1600 for loading a scene usingthe system and methods described herein.

At step 1602, a saved scene icon may be selected. In some embodiments,step 1602 may be the same as step 1502 and/or 1404. In some embodiments,the saved scene icon may be a visual representation of the saved sceneand/or the saved scene data. In some embodiments the saved scene iconmay be the same visual representation as the visual anchor node. In someembodiments, the saved scene icon may comprise the visual anchor node.

At step 1604, the saved scene icon may be moved from its defaultlocation. In some embodiments, step 1604 may be the same as step 1504and/or 1406. In some embodiments, step 1604 may comprise moving a totemaround while holding down a button on a totem. In some embodiments, step1602 may comprise pushing and releasing a button on a totem to selectthe object and step 1604 may comprise moving the totem around which maycause the saved scene to have corresponding movements as the totem.

In some embodiments, the saved scene may be loaded in the same locationas it was originally saved (e.g. the saved scene objects are in the samereal world location they were in when the scene was originally saved).For example, if the user created a scene in the user's kitchen, the usermay load the scene in the user's kitchen. In some embodiments, the savedscene may be loaded into a different location than the scene wasoriginally saved. For example, if the user saved a scene at theirfriend's house, but the user wants to continue interacting with thescene at home, the user may load the saved scene at the user's home. Insome embodiments, this split in process 1600 may correspond to the splitbetween 1432 and 1434 in process 1400.

At step 1608, the visual anchor node may be placed relative to the savedscene objects. In some embodiments, this may occur when the saved scenePCF matches the user's current PCF (i.e. the scene is loaded at the samelocation it was saved). For example, the application may be programmedto automatically place the saved scene objects (e.g. preview place) atthe same real world location as where they were saved. In this case, theinitial placement of the saved scene icon from its default locationfunctions to place the visual anchor node relative to the already placedsaved scene objects. In some embodiments, when the saved PCF matches thecurrent PCF, the system may automatically place, for example previewplace, the saved scene objects in the user's environment, and step 1608may determine the location for the saved scene anchor. In someembodiments, once the visual anchor node has been placed 1608, therelative spatial location between the visual anchor node and the savedscene objects may be fixed.

At step 1606, the visual anchor node may be placed relative to the realworld. In some embodiments, user input may be obtained on the locationof the visual anchor node when the saved scene PCF does not match theuser's current PCF, and/or if the user's current PCF cannot be obtained.Alternatively or additionally, the process may proceed to step 1608where the system may receive input to position the visual anchor noderelative to saved scene objects. For example, the application may beprogrammed to automatically place the visual anchor node relative to thesaved scene objects. In some embodiments, the visual anchor node may beautomatically placed at the center of the saved scene objects (as itsplacement relative to the saved scene objects). Other suitable relativeplacement method may be used.

At step 1610, the saved scene may be moved relative to the real world.By this step in process 1600, the visual anchor node has been placedrelative to the saved scene objects (steps 1608 or 1606) and the savedscene objects have been preview placed at an initial location in theuser's real world (for path 1608 the saved scene objects areautomatically placed in the same real world location as they were saved,and for path 1606, the saved scene objects are placed at a specifiedspatial configuration relative to the visual anchor node). The savedscene may optionally be moved at step 1610. In some embodiments, step1610 may be steps 1510, 1416-1420, and/or 1210. In some embodiments,step 1610 is not performed and process 1600 proceeds directly to step1612.

At step 1612, the saved scene may be instantiated. In some embodiments,step 1612 may be steps 1512, 1414, and/or 1212. In some embodiments, theapplication may have already loaded the saved scene into volatile memoryduring step 1602, so at step 1612 the scene may feed the full savedscene data into a render pipeline. The saved scene may then be capableof display to the user through the wearable device, for example wearabledevice 200, as an exact copy of the saved scene (e.g. same relativespatial relationship between saved scene objects), except optionally ata different location in the user's real world.

In some embodiments, the wearable system and the application may be usedinterchangeably. The application may be downloaded onto the wearablesystem, thus becoming part of the wearable system.

An example of what a user of an augmented reality system might see whileopening a saved scene is provided by FIGS. 21A-C. In this example, auser interface in which a user might activate a control to move thevisual anchor node 2110 is shown. FIG. 21A illustrates the user movingvisual anchor node 2110. In this example, the saved scene consists ofcubic objects, which are visible in a preview mode in FIG. 21A. In thisexample, the saved scene has a saved scene anchor node, which iscoincident with the visual anchor node. The saved scene objects have, inthis example, a predetermined relationship with respect to the savedscene anchor node and therefore a predetermined relationship withrespect to the visual anchor node. That relationship is indicated by thedotted lines visible in FIG. 21A.

FIG. 21B illustrates the user loading a saved scene with the visualanchor node in a desired location by activating a load icon 2120. Inthis example, user selection is shown by a line 2122, mimicking a laserpointer, to a selected icon. In an augmented reality environment, thatline might be manipulated by a user moving a totem, pointing a finger orany other suitable way. Activating a control, such as the LOAD controlin this example, may occur as a result of a user providing some otherinput, such as pushing a button on the totem, while an icon associatedwith the control is selected.

FIG. 21C illustrates virtual content 2130, here illustrated as blocks,being instantiated relative to the saved scene anchor node, which isaligned with the specified visual anchor node. On contrast with thepreview mode of FIG. 21A, the saved scene objects may be rendered withfull color, physics and other attributes of virtual objects.

Exemplary Embodiments

Concepts as discussed herein may be embodied as a non-transitorycomputer readable medium encoded with computer-executable instructionsthat, when executed by at least one processor, operate a mixed realitysystem of the type maintaining an environment for a user comprisingvirtual content configured for rendering so as to appear to the user inconnection with a physical world to select a saved scene, wherein eachsaved scene comprises virtual content and positions with respect to asaved scene anchor node and determine whether the saved scene anchornode associated with the selected scene is associated with a location inthe physical world. When the saved scene anchor node is associated witha location in the physical world, the mixed reality system may add thevirtual content to the environment at a location indicated by the savedscene anchor node. When the saved scene anchor node is not associatedwith a location in the physical world, the mixed reality system maydetermine a location in the environment and adding the virtual contentto the environment at the determined location.

In some embodiments, determining the location in the environment whenthe saved scene anchor node is not associated with a location in thephysical world comprises rendering a visual anchor node to the user andreceiving user input indicating a position of the visual anchor node.

In some embodiments, determining the location in the environment whenthe saved scene anchor node is not associated with a location in thephysical world comprises identifying a surface in the physical worldbased on similarity of affordances and/or attributes to a physicalsurface associated with the selected saved scene and determining thelocation with respect to the identified surface.

In some embodiments, determining the location in the environment whenthe saved scene anchor node is not associated with a location in thephysical world comprises determining the location with respect to theuser.

In some embodiments, determining the location in the environment whenthe saved scene anchor node is not associated with a location in thephysical world comprises determining the location with respect to thelocation of a virtual object in the environment.

In some embodiments, the computer-executable instructions configured toselect a saved scene may be configured to automatically select a savedscene based on user position within the physical world with respect tothe saved scene anchor node.

In some embodiments, the computer-executable instructions configured toselect a saved scene may be configured to select a saved scene based onuser input.

Concepts as discussed herein alternatively or additionally may beembodied as a non-transitory computer readable medium encoded withcomputer-executable instructions that, when executed by at least oneprocessor, operate a mixed reality system of the type maintaining anenvironment for a user comprising virtual content configured forrendering so as to appear to the user to receive user input selectingfrom a library a first pre-built virtual sub-component and a secondpre-built virtual sub-component and specifying a relative position ofthe first pre-built virtual sub-component and the second pre-builtvirtual sub-component; store as a scene virtual content comprising atleast the first pre-built virtual sub-component and the second pre-builtvirtual sub-component by storing saved scene data comprising dataidentifying the first pre-built virtual sub-component and the secondpre-built virtual sub-component and the relative position of the firstpre-built virtual sub-component and the second pre-built virtualsub-component; render an icon representing the stored scene in a menu ofa virtual user comprising icons for a plurality of saved scenes.

In some embodiments, the virtual content further comprises at least onebuilt component.

In some embodiments, the virtual content further comprises at least onepreviously saved scene.

Other Considerations

Each of the processes, methods, and algorithms described herein and/ordepicted in the attached figures may be embodied in, and fully orpartially automated by, code modules executed by one or more physicalcomputing systems, hardware computer processors, application-specificcircuitry, and/or electronic hardware configured to execute specific andparticular computer instructions. For example, computing systems caninclude general purpose computers (e.g., servers) programmed withspecific computer instructions or special purpose computers, specialpurpose circuitry, and so forth. A code module may be compiled andlinked into an executable program, installed in a dynamic link library,or may be written in an interpreted programming language. In someimplementations, particular operations and methods may be performed bycircuitry that is specific to a given function.

Further, certain implementations of the functionality of the presentdisclosure are sufficiently mathematically, computationally, ortechnically complex that application-specific hardware or one or morephysical computing devices (utilizing appropriate specialized executableinstructions) may be necessary to perform the functionality, forexample, due to the volume or complexity of the calculations involved orto provide results substantially in real-time. For example, a video mayinclude many frames, with each frame having millions of pixels, andspecifically programmed computer hardware is necessary to process thevideo data to provide a desired image processing task or application ina commercially reasonable amount of time.

Code modules or any type of data may be stored on any type ofnon-transitory computer-readable medium, such as physical computerstorage including hard drives, solid state memory, random access memory(RAM), read only memory (ROM), optical disc, volatile or non-volatilestorage, combinations of the same and/or the like. The methods andmodules (or data) may also be transmitted as generated data signals(e.g., as part of a carrier wave or other analog or digital propagatedsignal) on a variety of computer-readable transmission mediums,including wireless-based and wired/cable-based mediums, and may take avariety of forms (e.g., as part of a single or multiplexed analogsignal, or as multiple discrete digital packets or frames). The resultsof the disclosed processes or process steps may be stored, persistentlyor otherwise, in any type of non-transitory, tangible computer storageor may be communicated via a computer-readable transmission medium.

Any processes, blocks, states, steps, or functionalities in flowdiagrams described herein and/or depicted in the attached figures shouldbe understood as potentially representing code modules, segments, orportions of code which include one or more executable instructions forimplementing specific functions (e.g., logical or arithmetical) or stepsin the process. The various processes, blocks, states, steps, orfunctionalities can be combined, rearranged, added to, deleted from,modified, or otherwise changed from the illustrative examples providedherein. In some embodiments, additional or different computing systemsor code modules may perform some or all of the functionalities describedherein. The methods and processes described herein are also not limitedto any particular sequence, and the blocks, steps, or states relatingthereto can be performed in other sequences that are appropriate, forexample, in serial, in parallel, or in some other manner. Tasks orevents may be added to or removed from the disclosed exampleembodiments. Moreover, the separation of various system components inthe implementations described herein is for illustrative purposes andshould not be understood as requiring such separation in allimplementations. It should be understood that the described programcomponents, methods, and systems can generally be integrated together ina single computer product or packaged into multiple computer products.Many implementation variations are possible.

The processes, methods, and systems may be implemented in a network (ordistributed) computing environment. Network environments includeenterprise-wide computer networks, intranets, local area networks (LAN),wide area networks (WAN), personal area networks (PAN), cloud computingnetworks, crowd-sourced computing networks, the Internet, and the WorldWide Web. The network may be a wired or a wireless network or any othertype of communication network.

The systems and methods of the disclosure each have several innovativeaspects, no single one of which is solely responsible or required forthe desirable attributes disclosed herein. The various features andprocesses described above may be used independently of one another, ormay be combined in various ways. All possible combinations andsubcombinations are intended to fall within the scope of thisdisclosure. Various modifications to the implementations described inthis disclosure may be readily apparent to those skilled in the art, andthe generic principles defined herein may be applied to otherimplementations without departing from the spirit or scope of thisdisclosure. Thus, the claims are not intended to be limited to theimplementations shown herein, but are to be accorded the widest scopeconsistent with this disclosure, the principles and the novel featuresdisclosed herein.

Certain features that are described in this specification in the contextof separate implementations also can be implemented in combination in asingle implementation. Conversely, various features that are describedin the context of a single implementation also can be implemented inmultiple implementations separately or in any suitable subcombination.Moreover, although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to asubcombination or variation of a subcombination. No single feature orgroup of features is necessary or indispensable to each and everyembodiment.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orsteps. Thus, such conditional language is not generally intended toimply that features, elements and/or steps are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without author input or prompting,whether these features, elements and/or steps are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having,” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations, and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some, or all of the elements in the list. In addition, thearticles “a,” “an,” and “the” as used in this application and theappended claims are to be construed to mean “one or more” or “at leastone” unless specified otherwise.

As used herein, a phrase referring to “at least one of” a list of itemsrefers to any combination of those items, including single members. Asan example, “at least one of: A, B, or C” is intended to cover: A, B, C,A and B, A and C, B and C, and A, B, and C. Conjunctive language such asthe phrase “at least one of X, Y and Z,” unless specifically statedotherwise, is otherwise understood with the context as used in generalto convey that an item, term, etc. may be at least one of X, Y or Z.Thus, such conjunctive language is not generally intended to imply thatcertain embodiments require at least one of X, at least one of Y and atleast one of Z to each be present.

Similarly, while operations may be depicted in the drawings in aparticular order, it is to be recognized that such operations need notbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. Further, the drawings may schematically depict one more exampleprocesses in the form of a flowchart. However, other operations that arenot depicted can be incorporated in the example methods and processesthat are schematically illustrated. For example, one or more additionaloperations can be performed before, after, simultaneously, or betweenany of the illustrated operations. Additionally, the operations may berearranged or reordered in other implementations. In certaincircumstances, multitasking and parallel processing may be advantageous.Moreover, the separation of various system components in theimplementations described above should not be understood as requiringsuch separation in all implementations, and it should be understood thatthe described program components and systems can generally be integratedtogether in a single software product or packaged into multiple softwareproducts. Additionally, other implementations are within the scope ofthe following claims. In some cases, the actions recited in the claimscan be performed in a different order and still achieve desirableresults.

What is claimed is:
 1. A method of operating a mixed reality system,comprising, with at least one processor: receive input from the userselecting a saved scene in a saved scene library, wherein the savedscene comprises virtual content and position information indicatingposition of the virtual content, relative to a saved scene anchor node,in a first coordinate frame representing a first location in thephysical world; determine that the input from the user selecting thesaved scene was received at a second location different from the firstlocation, the determining comprising: determining a second coordinateframe based on a current environment of the user; comparing the secondcoordinate frame to the first coordinate frame representing the firstlocation; and determining that the second coordinate frame is differentfrom the first coordinate frame when it is determined that the secondcoordinate frame does not match the first coordinate frame; in responseto determining that the input from the user selecting the saved scenewas received at the second location different from the first location:determine a location for the saved scene anchor node relative to thesecond location; and control the display to render the virtual contentrelative to the determined location for the saved scene anchor node. 2.The method of claim 1, further comprising, with the at least oneprocessor: determine that the input from the user selecting the savedscene was received at the first location; and control the display torender the virtual content relative to the first location for the savedscene anchor node.
 3. The method of claim 1, wherein: the mixed realitysystem identifies one or more coordinate frames based on objects in thephysical world; and the method further comprises, with the at least oneprocessor, placing the saved scene anchor node at one of the one or moreidentified coordinate frames.
 4. The method of claim 1, furthercomprising, with the at least one processor, retrieve the virtualcontent from a remote server via a network interface.
 5. The method ofclaim 1, further comprising, with the at least one processor, controlthe display to render a menu comprising a plurality of iconsrepresenting saved scenes in the saved scene library; and whereinreceiving input from the user selecting the saved scene comprises userselection of an icon of the plurality of icons.
 6. The method of claim1, further comprising, with the at least one processor, render a virtualuser interface; and wherein receiving input from the user comprisesreceiving user input via the virtual user interface.
 7. The method ofclaim 1, further comprising, with the at least one processor, render avirtual user interface comprising a menu of a plurality of iconsrepresenting saved scenes in the saved scene library; and whereinreceiving input from the user selecting a saved scene in a saved scenelibrary comprises receiving user input via the virtual user interface,wherein the user input selects and moves an icon in the menu.
 8. Themethod of claim 1, wherein: the first coordinate frame comprises one ormore feature points in the physical world at the first location and thesecond coordinate frame comprises one or more feature points in thecurrent environment of the user; and comparing the second coordinateframe to the first coordinate frame comprises determining whether theone or more feature points of the first coordinate frame represent asame location in the physical world as the one or more feature points ofthe second coordinate frame.
 9. The method of claim 1, furthercomprising: in response to determining that the input from the userselecting the saved scene was received at the second location differentfrom the first location: render a preview of the virtual content at adefault location.
 10. The method of claim 1, further comprising:generating, in the display, a menu including: a first section forindicating saved scenes matching the second coordinate frame; and asecond section for indicating saved scenes that do not match the secondcoordinate frame, the second section including the saved scene; andreceiving the input from the user through the menu.
 11. A mixed realitysystem, comprising: a display; at least one sensor configured to acquireinformation about an environment of the mixed reality system; at leastone processor: a non-transitory computer readable medium encoded withcomputer-executable instructions that, when executed by the at least oneprocessor: receive input from a user selecting a saved scene in a savedscene library, wherein the saved scene comprises: virtual content andposition information indicating position of the virtual content relativeto a saved scene anchor node at a first location in the physical world;and a first collection of one or more points in the physical worldrepresenting the first location in the physical world; determine thatthe input from the user selecting the saved scene was received at asecond location different from the first location, the determiningcomprising: obtaining data from the at least one sensor; anddetermining, using the data from the at least one sensor, a secondcollection of one or more points in the physical world representing acurrent location of the user in the physical world; comparing the firstcollection of one or more points representing the first location to thesecond collection of one or more points representing the currentlocation of the user; and determining that the input from the userselecting the saved scene was received at the second location differentfrom the first location when it is determined that the first collectionof one or more points is different from the second collection of one ormore points; in response to determining that the input from the userselecting the saved scene was received at the second location differentfrom the first location: determine a location for the saved scene anchornode relative to the second location; and control the display to renderthe virtual content relative to the determined location for the savedscene anchor node.
 12. The mixed reality system of claim 11, wherein thecomputer-executable instructions are further configured to: determinethat the input from the user selecting the saved scene was received atthe first location; and control the display to render the virtualcontent relative to the first location for the saved scene anchor node.13. The mixed reality system of claim 11, wherein: thecomputer-executable instructions are further configured to: identify oneor more coordinate frames based on the acquired information about theenvironment of the mixed reality system; and place the saved sceneanchor node at one of the one or more identified coordinate frames. 14.The mixed reality system of claim 11, wherein: the system comprises anetwork interface; and the computer-executable instructions areconfigured to retrieve the virtual content from a remote server via thenetwork interface.
 15. The mixed reality system of claim 11, wherein:the system comprises a network interface; and the computer-executableinstructions are configured to control the display to render a menucomprising a plurality of icons representing saved scenes in the savedscene library; and receiving input from the user selecting the savedscene comprises user selection of an icon of the plurality of icons. 16.The mixed reality system of claim 11, wherein: the computer-executableinstructions are further configured to, when executed by the at leastone processor, render a virtual user interface; and thecomputer-executable instructions configured to receive input from theuser are configured to receive user input via the virtual userinterface.
 17. The mixed reality system of claim 11, wherein: thecomputer-executable instructions are further configured to, whenexecuted by the at least one processor, render a virtual user interfacecomprising a menu of a plurality of icons representing saved scenes inthe saved scene library; and receiving input from the user selecting asaved scene in a saved scene library comprises receiving user input viathe virtual user interface, wherein the user input selects and moves anicon in the menu.
 18. A non-transitory computer readable medium encodedwith computer-executable instructions that, when executed by at leastone processor, perform a method of operating a mixed reality system,comprising, with the at least one processor: receive input from the userselecting a saved scene in a saved scene library, wherein the savedscene comprises: virtual content and position information indicatingposition of the virtual content relative to a saved scene anchor node ata first location in the physical world; and a saved three-dimensional(3D) mesh representing the first location in the physical world, thesaved 3D mesh generated from a depth map of the first location;determine that the input from the user selecting the saved scene wasreceived at a second location different from the first location, thedetermining comprising: accessing the saved 3D mesh representing thesaved scene; and determining that the saved 3D mesh is different from a3D mesh generated from a depth map of a current environment of the userin the physical world; in response to determining that the input fromthe user selecting the saved scene was received at the second locationdifferent from the first location: determine a location for the savedscene anchor node relative to the second location; and control thedisplay to render the virtual content relative to the determinedlocation for the saved scene anchor node.
 19. The non-transitorycomputer readable medium of claim 18, wherein the computer-executableinstructions are further configured to: determine that the input fromthe user selecting the saved scene was received at the first location;and control the display to render the virtual content relative to thefirst location for the saved scene anchor node.
 20. The non-transitorycomputer readable medium of claim 18, wherein the method furthercomprises determining one or more coordinate frames based on theacquired information about the environment of the mixed reality system;and placing the saved scene anchor node at one of the one or moreidentified coordinate frames.
 21. The non-transitory computer readablemedium of claim 18, wherein: the system comprises a network interface;and the computer-executable instructions are configured to control thedisplay to render a menu comprising a plurality of icons representingsaved scenes in the saved scene library; and receiving input from theuser selecting the saved scene comprises user selection of an icon ofthe plurality of icons.
 22. The non-transitory computer readable mediumof claim 18, wherein: the computer-executable instructions are furtherconfigured to, when executed by the at least one processor, render avirtual user interface; and the computer-executable instructionsconfigured to receive input from the user are configured to receive userinput via the virtual user interface.
 23. The non-transitory computerreadable medium of claim 18, wherein: the computer-executableinstructions are further configured to, when executed by the at leastone processor, render a virtual user interface comprising a menu of aplurality of icons representing saved scenes in the saved scene library;and receiving input from the user selecting a saved scene in a savedscene library comprises receiving user input via the virtual userinterface, wherein the user input selects and moves an icon in the menu.